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(57) Abstract: A scalable access filter that is used together with others like it in a virtual private network to control access by users 
at clients in the network to information resources provided by servers in the network. Each access fUter use a local copy of an access 
control data base (3845) to determine whether an access request is made by a user. Each user belongs to one or more user groups and 
each information ressource belongs to one or more information sets. Access is permitted or denied according to access policies which 
define access in terms of the user groups and information sets. The first access filter in the path performs the access check, encrypts 
and authenticates the request; the other access filters in the path do not repeal the access check. The interface used by applications to 
determine whether a user has access to an entity is now an SQL query. The policy server (3811) assembles the information needed 
for the response to the query from various information sources, including source external to the policy server. 
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Background of the Invention 

1. Field of the Invention n.,eries and relates more 

I ..c aenerallv to systems for respondmg to queries and 
The invention relates generally to y j^j^ ,,„^uccess to data. 

specifically to such systems as components of systems whi 

2. Description of Related Art u has done so by providing 
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The very ease with which computer systems may exchange information via the Internet 
has, however, caused problems. On the one hand, it has made accessing information 
easier and cheaper than it ever was before; on the other hand, it has made it much harder 
to protect information. The Internet has made it harder to protect information in two 
5 ways: 

• It is harder to restrict access. If information may be accessed at all via the 
Internet, it is potentially accessible to anyone with access to the Internet. Once 
there is Internet access to information, blocking skilled intruders becomes a 
difficult technical problem. 

10 • It is harder to maintain security en route through the Internet. The Internet is 

implemented as a packet switching network. It is impossible to predict what route 
a message will take through the network. It is further impossible to ensure the 
security of all of the switches, or to ensure that the portions of the message, 
including those which specify its source or destination, have not been read or 

1 5 altered en route. 

FIG. 1 shows techniques presently used to increase security in networks that are 
accessible via the Internet. FIG. 1 shows network 101, which is made up of two separate 
internal networks 103(A) and 103(B) that are connected by Internet 111. Networks 

20 103(A) and 103(B) are not generally accessible, but are part of the Internet in the sense 
that computer systems in these networks have Internet addresses and employ Internet 
protocols to exchange inforrhation. Two such computer systems appear in FIG. 1 as 
requestor 105 in network 103(A) and server 113 in network 103(b)i Requestor 105 is 
requesting access to data which can be provided by server 1 13. Attached to server 1 13 is 

25 a mass storage device 1 15 that contains data 117 which is being requested by requestor 
105. Of course, for other data, server 1 13 may be the requestor and requestor 105 the 
server. Moreover, access is to be understood in the present context as any operation 
which can read or change data stored on server 113 or which can change the state of 
server 113. In making the request, requestor 105 is using one of the standard TCP/IP 
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protocols. M us^ he«. a is a descripUo^ of a se. of me^ages .ha. c«. be used 

10 exchange information bewew compiner sys.ems. 
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05 s«,Les.gesac^rdin,«>«.epro»co>»server U.s.n.eme. address and 

sends n^ssages according .0 *e pro.oco, .o re,ues»r iO.s .n^e, addr^. Bo* 

•n travi^J between internal network 103(A) and 103(B) by 
the request and response will travel between imcm 

r! l!t 111 If server 113 permits requestor 105 to access the data, some of the 
internet 111. If server P ^^^^.^^ ^.^^ 

messages flowing from server 113 to requestor 

requested data 117. The software components of server 113 w 

messages as required by the protocol are termed a service. 

, . .i,c in^fA and B) wants to be sure that only users of 
If the owner of internal networks 103(A and a) a 

computer systems connected directly to networks 103(A and B) can access data 1 7 and 
lents of the request and response are not known outside those netwo^ 

. • ..^ thct cprver 1 13 does not respond to requests 
^wner must solve two problems: makmg sure that server 11 :>aoc f 

:"u»r s. Js o*e. .han .ose conneced » .e in.en., ne^o^ a. n^.n. 

snre .ha. peopie wi. access J — la.: i. 

response while *ey are in Bans,. ttiroughlnKTie. in. iv^ 

possible .o achieve .hese goals are^i.-^ and «»»*g using e„cryp..oa 

Concep.uany. a firewall is a barrier between an in.ernal ne^ork and U.. res. of In^me. 
H P^lls appear a. .09(A) and (B, Firewall .09CA) pr«ec« in.emal ne«, ^ 
1 firewTl 109(B) pro«o« imemal ne«ork 103(B). Firewalls are .mplemenud 

103(A) and firewall ' P i„^„^ „ flre poin. where 

. by .neans of a gateway ™»' ^ ' "-"^^^ ...eway is an a^. 

an inumal network is connected to the Internet. 

a set of software and hardware components ,n the computer system 
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has the right to access the information. Otherwise, it discards the request. Two such 
access filters, access filter 107(A), and access filter 107(B), appear in FIG. 1 . 

A source has the right to access the requested information if two questions can be 
5 answered affirmatively: 

• Is the source in fact who or what it claims to be? 

• Does the source have the right to access the data? 

The process of finding the answer to the first question is termed authentication, A user 
authenticates himself or herself to the firewall by providing information to the firewall 
10 that identifies the user. Among such information is the following: 

• information provided by an authentication token (sometimes called a smartcard) 
in the possession of the user; 

• the operating system identification for the user's machine; and 

• the IP address and the Internet domain name of the user's machine. 

15 The information that the firewall uses for authentication can either be in band, that is, it is 
part of the protocol, or it can be out of band, that is, it is provided by a separate protocol. 

As is clear from the above list of identification information, the degree to which a 
firewall can trust identification information to authenticate a user depends on the kind of 

20 identification information. For example, the IP address in a packet can be changed by 
anyone who can intercept the packet; consequently, the firewall can put little trust in it 
and authentication by means of the IP address is said to have a very low trust level On 
the other hand, when the identification information comes fi-om a token, the firewall can 
give the identification a much higher trust level, since the token would fail to identify the 

25 user only if it had come into someone else's possession. For a discussion on 
authentication generally, see S. Bellovin and W, Cheswick, Firewalls and Internet 
Security, Addison Wesley, Reading, MA, 1994. 

In modem access filters, access is checked at two levels, the Internet packet, or IP level, 
30 and the application level. Beginning with the IP level, the messages used in Internet 

4 


0079434A1J_> 


PCT/USOO/1707? 

I 

WO 00/79434 

in nackcB called datagrams. Each such packet has a header which 
protocols are carrted n packed ca i ^ ^ 
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5 computer. Services R>r ^ has a set of rules 
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• , .1 « „<!ualW done in the firewall by proxies. A 
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transit through Internet 111. That is prevented by means of tunneling using encryption. 
This kind of tunneling works as follows: when access filter 107(A) receives an IP packet 
from a computer system in internal network 103(A) which has a destination address in 
internal network 103(B), it encrypts the IP packet, including its header, and adds a new 
5 header which specifies the IP address of access filter 107(A) as the source address for the 
packet and the IP address of access filter 107(B) as the destination address. The new 
header may also contain authentication information which identifies access filter 107(A) 
as the source of the encrypted packet and information from which access filter 1 07(B) 
can determine whether the encrypted packet has been tampered with. 

10 

Because the original IP packet has been encrypted, neither the header nor the contents of 
the original IP packet can be read while it is passing through Internet 111, nor can the 
header or data of the original IP packet be modified without detection. When access filter 
107(B) receives the IP packet, it uses any identification information to determine whether 

15 the packet is really from access filter 107(A). If it is, it removes the header added by 
. access filter 1 07(A) to the packet, determines whether the packet was tampered with and 
if it was not, decrypts the packet and performs IP-level access checking on the original 
header. If the header passes, access filter 107(B) forwards the packet to the IP address in 
the internal network specified in the original header or to a proxy for protocol level 

20 access control. The original IP packet is said to tunnel through Internet 111. In FIG. 1, 
one such tunnel 112 is shown between access filter 107(A) and 107(B). An additional 
advantage of tunneling is that it hides the structure of the internal networks from those 
who have access to them only from Intemet 111, since the only unencrypted IP addresses 
are those of the access filters. 

25 

The owner of internal networks 103(A) and 103(B) can also use tunneling together with 
Intemet 1 1 1 to make the two internal networks 103(A and B) into a single virtual private 
network (VPN) 1 19. By means of tunnel 1 12, computer systems in network 103(A) and 
103(B) can communicate with each other securely and refer to other computers as if 
30 network 103(A) and 103(B) were connected by a private physical link instead of by 
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Internet 111. Indeed, virtual private network 119 may be extended to include any user 
who has access to Internet 1 1 1 and can do the following: 

. encrypt Internet packets addressed to a computer system in an internal network 
103 in a fashion which permits an access filter 107 to decrypt them; 
5 . add a header to the encr^ted packet which is addressed to filter 107; and 

authenticate him or herself to access filter 1 07. 
For example, an employee who has a portable computer that is connected to Internet 1 1 
and has the necessary encryption and authentication capabilities can use the vrtua 
private network to securely retrieve data from a computer system in one of the mtemal 
10 networks. 

once inten-al nctwortcs begin .sing Interne, addressing and In«me, protocols and are 
connected into virtual private networks, the browsers that have been developed for the 
imemet can be used as well in the internal networks 103. and front the point of v,ew of 
, s the user, there is no difference between accessing data in Interne. 1 1 1 and accessing ,t m 
internal nenvork 103. In<en>al network 103 has thus become an in^U that >s an 
internal ne.v.ork .ha, has d,e same user inrerface as Imeme. 1 1 1 . Of course, once all o 
the imemal networks belonging to an entity have been combined into a single v.rtual 
private intranet, the access control issues characteristic of the Internet arise again-excep. 
.0 this .ime wi* regard to InU^ a»ess .0 data. While firewalls a. Ute points wh^ me 
internal networks are connected to Internet 1 1 1 are perfectly sufficient to keep ou.s,ders 
from accessing data in the internal networks, they canno. keep from accessing 

flrat data. For example, it may be just as impor«„. «> a company to protect its personnel 
data from its employees as to pro»« i. from outsiders. A. the same time, the company 
25 may v,ant to make its World Wide Web site on a compuKr sysum in one of .he mtemal 
networks 103 easily accessible to anyone who has access to Internet 111. 

One solution to the s«urity problems posed by vir«al priva.e intranets is to use firewalls 
,0 .bdivide the internal networks, as well as to pro.ec. *e interna, ne^vorks from 
30 unauthorized access via the Internet. Present-day access filters 107 are designed for 
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protecting the perimeter of an internal network from unauthorized access, and there is 
typically only one access filter 107 per Internet connection. If access filters are to be 
used within the internal networks, there will be many more of them, and virtual private 
networks that use multiple present-day access filters 107 are not easily scalable^ that is, 
5 in virtual private networks with small numbers of access filters, the access filters are not a 
serious burden; in networks with large numbers of access filters, they are. The access 
filters described in the part of the present patent application which precedes the section 
titled Generalization of the techniques employed in access filter 203 in fact solves the 
scalability problems of prior-art access filters and thus greatly ease the implementation of 
10 networks with large numbers of access filters. 

in the course of further work on the access filters described in the first part of the present 
patent application, it has become apparent that the techniques developed to do access 
checking in access filter 203 would be even more useful if they could be generalized: if 

15 * they could be used in contexts other than access filters operating at the IP filter or Internet 
protocol levels and if they could be made to be extensible, so that policies could be made 
not only for access to information sets, but for any action that could be performed on an 
entity accessible through a computer system, so that user groups could include any kind 
of entity that can perform an action through a computer system, and so that information 

20 sets could become resource sets, where a resource is any entity that can be controlled via 
a computer system. It further became apparent that policies would be even more useful if 
they were permitted to include a temporal component, for example, a component which 
permitted a certain group of users access to certain resources only during non-working 
hours and that it would also be beneficial to be able to associate attributes with a policy 

25 that described how the policy's action was to be performed. For instance, a policy might 
specify not only that members of a given user group could access a given resource, but 
also the class of network service to be used for the access. 

Development work has continued on the generalized policy server of the parent of the 
30 present patent application, and significant improvements have resulted. One improvement 
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It le« part of the infonnation needed to make an access detenrnnation is often 
available before the request for access is made. 

Another improvement solves a problem of the access control sys«ms of *e p.en. 
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u.er eroup membership determination and the sources or m 
7JZ in the access cental sys.» described in the parent of the present patent 

ion' "stem administrators could define information to be us^ to determine user 
application, sys.^ ^^^^ ^^^^ „ 
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not Dossible to use infomiation from a source such as a business gen 
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Summary of the Invention 

The invention attains the foregoing objects as follows: 

• The improved generalized policy server provides an interface to the policy- 
enabled component which presents the access control system as a virtual 

5 relational database table in which there is a row for every user-information source 

combination; to determine whether a user has access to an information source, the 
policy-enabled component addresses a query indicating the user and the 
information source to the table; the result indicates at least whether the user has 
access. The relational database table is virtual because a real table would tend at a 

10 minimum to be very large and would in very many cases simply be undefmable. 

A virtual database service in the improved generalized policy server assembles 
the information needed for the query result using data sources that are accessible 
to it. In a preferred embodiment, the query is written in the well-known SQL 
language and the virtual database service emulates standard remotely-accessible 

15 database systems. 

• The improved generalized policy server permits administrators of the access 
control system to define methods of obtaining information about users and 
associating these methods with user groups. The methods may define ways of 
collecting information from the user, ways of collecting information about the 

20 user from external sources, and ways of using the collected information to 

authenticate the user, to determine the membership of the user in a user group, 
and to provide information about the user to the policy-enabled component. 
Other objects and advantages of the invention will be apparent to those skilled in the arts 
to which the invention pertains upon perusing the following Detailed Description and 
25 Drawing, wherein: 

Brief Description of the Drawing 

FIG. 1 is an overview of techniques used to control access of information via the 
Internet; 
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FIG. 2 is an overview of a VPN that uses access filters incorporating the techniques 

disclosed herein; ^,Us used in the access fUters; 
FIG. 3 is an overview of an access con vpn that uses access filters 

FIG. 4 shows access checking and tunnehng xn a VPN that 
5 incorporating the techniques disclosed herein; 

K« a "rnamer" to infonnation in the V PN ; 
FIG. 5 shows access by a roamer ^^^^^^ 

FIG. 6 is a table used in defining the relationship between sensitivity 

authentication and encryption techniques; 
FIG. 7 is an example of the application of SEND; 
10 FIG. 8 is a flow chart of the policy creation process; 
FIG. 9 shows a display used to define user groups; 
FIG. 10 shows a display used to define information sets; 
FIG 11 shows a display used to define access policies; 

VPN and d>e servers, semces, mi resources at each site; 
P.G 1*1 a schemaof *e par, of access co„»ol database 301 .ha. defines ^.cres; 
^"•:::s:ln»omepa«„faccesscon.o,da..ase301*a.de«nesservers; 

FIG. 18 shows Redisplay used in drelnuaMapinUrface. 

no. 19 Shows how changes are made » access conttol database 301 

r *u «^/.Vi;t*>rtiire of axi access filter 2Ui , 
FIG 20 is a detailed block diagram of the architecture 

^ thP structure of an MMF file 2303; 
25 FIG. 21 is a diagram of the structure ui 

irir n is a diagram of a message sent using SKIP; 

nos 3 A B. .1 C are a table of the MMF mes entployed in a preferred enrbodrnrent. 
no i is a diagram of an implemen^tion of the h>.raMap interf.ce; 
FIG. 25 is a diagram illusOraUng delegation in VPN 201 ; 
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FIG. 26 is a block diagram of an action control system where policy checking has been 
separated from policy enforcement; 

FIG. 27 is a block diagram of an action control system with a variety of policy-enabled 
devices; 

5 FIG. 28 shows a syntax used to define generalized policies; - 
FIG. 29 shows an overview of policy database 2901 in a preferred embodiment; 
FIG. 30 shows an implementation of attributes and time intervals in policy database 
2901; 

FIG. 31 shows a window that lists all defined schedules; 
10 FIG. 32 shows a window used in a preferred embodiment to define a schedule rule; 

FIG. 33 shows a window used in a preferred embodiment to apply an interval of time to a 
policy; 

') 

FIG. 34 shows a window used in a preferred embodiment to display attributes; 
FIG. 35 shows a window used in a preferred embodiment to assign attributes to subjects; 
15 FIG. 36 shows a window that is used to display and modify the definition of an attribute 

in a preferred embodiment; 
FIG. 37 shows a window that is used to display and modify the definition of a feature in 

a preferred embodiment; 
FIG. 38 is a block diagram of a general policy server that incorporates the improved 
20 message protocol and the technique for obtaining information from sources 

other than the UIC and the access control database; 
FIG. 39 shows the top level of an application programmer's interface to the improved 
message protocol; 

FIG. 40 shows a function ConclavePolicyAllowed which implements the 
25 improved message protocol; 

FIG. 41 shows a schema for a query interface to the generalized policy server; 

FIG. 42 shows first examples of queries to VDB Service 38 13 and their results; 

FIG. 43 shows second examples of queries to VDB Service 3813 and their results; 

FIG. 44 is a detail of the contents of policy database 4401 from which policy DB 3825 is 
30 compiled; 
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FIG 45 is a flowchart of custom user information retrieval; 

FIG. 4MS a .„fi„:,i«„ of a custom authentication type; 

: :::r;r :r .o„. ^ . - 

. -™ — ^„,„,,>„, , au,he„.ic«io„ type and 

a user group and ■"f°™«'°"^"' ^„ aefme custom a«*»ticaUon 

FIG. 49 shows rabies in database 4401 that are useo 

• ^.fhase 4401 that are used to define custom 
nc. 50 shows additional tables m database 44U1 

authentication types; ,„tt,ent,ca.ion form 3807 »,d 

FIG. 51 shows a browser wrndow that is proouceo , 

local configuration information 3809. 
FIG 52 shows how the information collected v,a the browser w 

returned to the virtual database service in a query; 
no. 53 Shows the r^ponse to the ,ue^ of ^^^^^^ 
FIG. 54 is a conceptual overview of the virtual oaia 

■„ the drawings have at least three digits. The ^vo righnttost 
T,. reference number m the towing ^ ^.^^ ^ 

rLple. an item wiU, refetence number 203 firs, appears ,n HO. 2. 

Detailed Description „„, fe, nrovide an overview of access filters that 

^ — 7'::' rirl access . — of how they 
« are easily scalable, of how *ey ar ^ ^^,,,„„„ 
ean be used to construct vtrtual pnvate networ 


manner in which an individual filter controls access. 
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A Network with Access Filters that do not Interfere with Scalability: FIG* 2 
FIG. 2 shows a virtual private network (VPN) 201 in which access to data is controlled 
by access filters that are designed to avoid the problems posed by multiple access filters.. 
VPN 201 is made up of four internal networks 103 which are connected to each other by 
5 Internet 121. Also connected to VPN 201 via Internet 121 is a roamer 217, that is, a 
computer system which is being used by a person who may access data in intranet 201, 

but is connected to the internal networks only by Internet 121. Each internal network 103 

* 

has a number of computer systems or terminals 209 belonging to users and a number of 
servers 21 1 which contain data that may be accessed by users at systems or terminals 209 

10 or by a user at roamer 217. However, no computer system or terminal 209 or roamer 217 
is connected directly to a server 211; instead, each is connected via an access filter 203, 
so that all references made by a user at a user system to a data item on a server go 
through at least one access filter 203. Thus, user system 209(i) is connected to network 
213(i), which is connected to access filter 203(a), while server 211(i) is connected to 

15 network 215(i), which is also connected to access filter 203(a), and any attempt by a user 
at user system 209(i) to access data on server 21 l(i) goes through access filter 203(a), 
where it is rejected, if the user does not have the right to access the data. 


If VPN 201 is of any size at all, there will be a substantial number of access filters 203, 
20 and consequently, scaling problems will immediately arise. Access filters 203 avoid 
these problems because they are designed according to the following principles: 

• Distributed access control database. Each access filter 203 has its own copy of 
the access control database used to control access to data in VPN 201. Changes 
made in one copy of the database are propagated to all other copies. 

25 • Distributed administration. Any number of administrators may be delegated 

responsibility for subsets of the system. - AH administrators may perform their 
tasks simultaneously. 

• Distributed access control. Access control functions are performed at the near- 
end access filter 203. That is, the first access filter 203 in the path between a client 

30 and the server determines if the access is allowed and subsequent access filters in 
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. nf the design will be discussed in more detail below. 
10 All of these aspects of the design win 

f.it*.r 103 may be implemented in any 
U Should he pointed out . this point that ac^» f^JOS ^ y 

fashron »Kich ensures that a„ references to ^ ,,,, ,„ , 
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• embodiments, access filter 203 may D P 

system and/or may be implemented in a router m VPN 201 . 

,0 Distribute! policy Database: FIG. 3 ^„ 

Each access filter 203 has a copy of an access co ^^^^ ^^^^^^ 

1 •« VP>J 201 One access inter, snuwu 
„,evan. to access control ,nV ^ ,,^33 

FIG. 2. has a master copy 205 of access ^he master copy 205 is the one that 

- -a> is te.ed the ^^^^Z^ JL control da.base 
25 is used to initialize new access filters P ^^^^p 

301. -backup for the n^ster policy m^^^^ ^^^^ ,,,,, 

207 is a mirror image of master ^^^^^^^^ ,,,,^e 301 and 

software for generating reports t.om ^'^^^^^^^^^^ ,,^3 control database 
.om logs obtained from all other ac<.ss ^^.^ ^ , .^scribed 

30 301 may be altered by any user who has the access q 
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in more detail later, any such alteration is propagated first to master policy manager 205 
and then to all of the other access filters 203 in virtual private network 201 . 

FIG. 3 is a conceptual overview of access control database 301. The primary function of 
5 the database is to respond to an access request 309 frorh access filter 203 which identifies 
a user and an information resource with an indication 311 of whether the request will be 
granted or denied. The request will be granted if both of the following are true: 
• The user belongs to a user group which data base 301 indicates may access an 
information set to which the information resource belongs; and 
10 • the request has a trust level which is at least as high as a sensitivity level belonging to 
the information resource. 
Each user belongs to one or more of the user groups and each information resource 
belongs to one or more information sets; if none of the user groups that the user belongs 
to is denied access to an information set that the resource belongs to and any of the user 
15 groups that the user belongs to is allowed access to any of the information sets that the 
information resource belongs to, the user may access the information resource, provided 
.that the request has the requisite trust level. 


The sensitivity level of a resource is simply a value that indicates the trust level required 
20 to access the resource. In general, the greater the need to protect the information 
resource, the higher its sensitivity level. The trust level of a request has a number of 
components; 

• the trust level of the identification technique used to identify the user; for 
-example, identification of a user by a token has a higher trust level than 

25 identification of the user by IP address. 

• the trust level of the path taken by the access request through the network; for 
example, a path that includes the Internet has a lower trust level than one that 
includes only internal networks. 

• if the access request is encrypted, the trust level of the encryption technique used; 
30 the stronger the encryption technique, the higher the trust level. 
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The trust level of the identification technique and the trust level of the path are each 
Ldered separate.. The trust level of the path .a. however, .e --^^^ 
level of the encryption technique used to enc^pt the access request. If the r^u^J 
encrypted with an encryption technique whose trust level is higher that the trust level of 
S poln of the path, the trust level of the portion is increased to the trust level of the 
Option technique. Thus, if the trust level of a portion of a path is .ss than requ^ 
Lie sensitivity level of the resource, the problem can be solved by encrypting the 
access request with an encryption technique that has the necessary trust level. 

,0 The information contained in database 301 may be divided into five broad categories: 
. user identification information 313. which identifies the user; 

user groups 315. which defines the groups the users belong to; 
. information resources 320, which defines the individual information items subject 

to protection and specifies where to find them; 
,5 . informationsets321.whichdefinesgroupsofinformationresources; 

. trust information 323. which specifies the sensitivity levels of infonnauon 
resources and the trust levels of user identifications and network paths; and 

. policy information 303, which defines access rights in terms of user groups and 
objects in VPN 201. 

. . u A- A^A Jntn access DoUcv 307, administrative policy 305. 
Policy information is fiirther divided mto access poncy , 

and policy maker policy 306. 

. access policy 307 defines rights of access by user groups to infonnauon sees; 
. ^„i„is»«ive poHcy 305 defines rights of user groups .o def,„e/de.«e/ 

objecu in VPN 201 . Among ,he objecu are ac^ss policies, intormation sets, user 
groups, locations in VPN 201, servers, and services; and 
. policy maker policy 306 defines rights of user groups to make access pohcy for 

information sets. , «„rt5nn<! 

The user ^oups specified in the administrative policy and policy maker pohcy portions 
The user groups v ■ ,,,^„tnrK In VPN 201, administrative authority 

of database 301 are user groups of admimstrators. In VfN ^ui, 
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is delegated by defining groups of administrators and the objects over which they have 
control in database 301. Of course, a given user may be a member of both ordinary user 
groups 317 and administrative user groups 319. 

5 Identification of Users 

User groups identify their members with user identification information 313. The 
identification information identifies its users by means of a set of extensible 
identification, techniques. Presently, these identification techniques include X.509 
certificates, Windows NT Domain identification, authentication tokens, and IP 
10 address/domain name. The kind of identification technique used to identify a user 
determines the trust level of the identification. 

Where strong identification of a user or other entity that an access filter 203 
communicates with is required, VPN 201 employs the Simple Key Management for 
Internet Protocols (SKIP) software protocol, developed by Sun Microsystems, Inc. The 

15 protocol manages public key exchange, authentication of keys, and encryption of 
sessions. It does session encryption by means of a transport key generated from the 
public and private keys of the parties who are exchanging data. Public keys are included 
in X.509 certificates that are exchanged between SKIP parties using a separate protocol 
known as the Certificate Discovery Protocol (CDP). A message that is encrypted using 

20 SKIP includes in addition to the encrypted message an encrypted transport key for the 
message and identifiers for the certificates for the source and destination of the data. The 
recipient of the message uses the identifiers for the certificate of the source of the 
message to locate the public key for the source, and uses its keys and the source's public 
key to decrypt the transport key and uses the transport key to decrypt the message. A 

25 SKIP message is self-authenticating in the sense that it contains an authentication header 
which includes a cryptographic digest of the packet contents and modification of any 
kind will render the digest incorrect. For details on SKIP, see Ashar Aziz and Martin 
Patterson, Simple Key-Management for Internet Protocols (SKIP), which could be found 
on 2/28/98 at http://www.skip.org/inet-95.html. For details on X.509 

18 


0079434A1 I _> 


PCT/US00/n018 


wo (KW79434 


,H found on 9/2/97 at 

«,e description that could be 
cenification, sec * o„,,„,dillo/p/pdoc2 .htm. 

ht;i;p://"ww. tnbo.com/tR 

. bv access filters 203 to identify themselves to od.« 
,„ VPN 201. SKIP is also used by acce« ^^^^^ ^^^^ ^ 

^cess filters 203 in d>e VPN ""^ «> „ -„en,i& users when 

.ccess filtets 203 ^ also use *c ^^^^.r^^ ^ 
„ey arc performing access checks. Su h an ^^^^^^^^ ^ 

has a correspondingly high trust level. ^ ^^j^,^ can 

^rtincate is for trustworthy iden„ » ^ ,^ ,„,^,„„ 

be used for user ident,flca..on because they 

about the user. 

nter 203 uses the followhrg fields of intorn«.ion fion, d,e certificates: 
Access filter 203 uses m certificate is invalid. 

. ..piration f>ate. :;:'J:X^^ .y pair, as used . the SKIP- 

Public Key. The public half of a pu" 

hased cryptography «>at conclave us«. ^ 

Certificate Authority Signature, -nre dt^mg 
authority that issued the certificate. 

. serial Nun-ber for the certify 

The subject name inw»" 

:r:»rsrue na.e of ^ - — - ^• 

r CO.. The coun. in which the subject resides. Country codes are 2.1e.er 

codes specified in the X.509 the city in 

/T ^ location at which the suoject 
. reality (L). The loc^^n ,„ea.ion-related value. 

«hich the subject resrdes, but ^ , 

. • /r»^ The organization lo vviuv 
, Organization (O). i ne org 

the organization's name. 


15 


20 


25 


30 19 


wo 00/79434 PCT/USOO/17078 


• Organizational Unit (OU). The organizational unit for the subject. This is usually 
the department for the subject, for example, "sales". The X.509 certificate allows 
up to four of these fields to exist. 

A Certificate Authority used with access filters 203 issues certificates with all of these 
5 fields. Further, the four OU fields can be used to define additional categories. The 

information used to describe a user in a certificate is available to the administrators of 

data base 301 for use when defining user groups. If the information in the certificates 

I. 

properly reflects the organizational structure of the enterprise, a certificate will not only 
identify the user, but show where the user fits in the enterprise's organization and to the 
10 extent that the user groups in data base 301 reflect the organizational structure, the user 
groups that the user belongs to. 

As will be explained in more detail later, one way in which members of user groups may 
be defined is by certificate matching criteria which define the values of the fields which 

15 a certificate that belongs to a member of a given user group must have. The certificate 
matching criteria can be based on as few or as many of the above fields as desired. For 
example, the certificate matching criteria for the Engineering user group might be 
the organization field and an organization unit field specifying the engineering 
department. Other information that identifies a user may be used to define members of 

20 user groups as well. 

Information Sets 

Information sets hold collections of individual information resources. A resource may be 
as small as an individual WWW page or newsgroup, but most often it will consist of a 
25 Web directory tree and its contents, FTP accounts, or major Usenet news categories. 
Two information sets, 2190) shown in one of the servers of FIG. 2. While it 

is completely up to the administrators of access control database 301 to determine what 
information is included in an information set, the information in a given set will generally 
be information that is related both topically and by intended audience. Example 
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information ^ for a Ration migh, be m policies. HR Personnel 

Records, and Public Information. 

Access Policy 307 

Conceptually, access policy 307 consists of simple statements of the form-. 

Engineers allowed access to engineering data 

Internet allowed access to public web site 

The flrst colunn specifies user groups; the last column specifies information sets. The 

middle column is the access policy— allow or deny. 

Database 301 pemils hierarchical definition of both user groups and information sets. For 
example, the Engir^eers user group may be defined as including a Hardware 
Engineers user group, a Software Engineers user group, and a Sales 
Engineers user gmup . Similarly, the engineering data information set may be 
defined as including a hardware engineering data infomtation set, a 
software engineering data information set, and a sales engineering 
data information set. Access rights are inherited within hierarchies of user groups. 
Thus a user who belongs to .he Hardware Engineers user group also automaucally 
belongs «> the Engineers user group for access checking purposes. Access nghts are 
similarly inherited within hierarchies of information sets. An information resource that 
belongs to the hardware engineering information set also automatically belongs to 
the engineering data infonnation set for access checking purposes. Thus, if there ,s 
an access policy that gives Engineers access to engineering data, any user 
who is a member of one of the three user groups making up Engineers may access any 
information resource that belongs to any of the three information sets making up 
engineering data. The use of inheritance in the definitions of user groups and 
information sets greatly .«iuces «.e number of access policies 307 that are required .n 
access control database 301. For instance, in the above example, a single access pohcy 
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gives all engineers access to all engineering data. Inheritance also makes it possible to 
define virtually all access policies in terms of allowing access. Continuing with the above 
example, if there is a user group Salespeople that does not belong to Engineers 

and there is an access policy that gives that user group access to sales engineering 

5 data, a user who is a member of Salespeople will be able to access sales 

engineering data, but not software engineering data or hardware 

engineering data. 

A user may of course belong to more than one user group and an information resource 
10 may belong to more than one information set. There may also be different access policies 
for the various user groups the user belongs to and the various information sets the 
information resource belongs to. When faced with multiple access policies that apply to 
the user and to the information resource that the user is seeking to access, access filter 
203 applies the policies in a restrictive, rather than permissive way: 
15 • If multiple policies allow or deny a user group's access to an information set, 

policies that deny access prevail. 

• If a particular user is a member of multiple user groups, and multiple policies 
allow or deny access to the information set, policies that deny access prevail. 

20 What user groups a user belongs to may vary according to the mode of identification used 
to identify the user. Thus, if no access policies apply for the user groups that the user 
belongs to according to the modes of identification that the user has thus far provided to 

access filter 203, access filter 203 may try to obtain additional identification information 

« 

and determine whether the additional identification information places the user in a user 
25 group for which there is a policy regarding the resource. Access filter 203 may obtain the 
additional identification information if: 

• The user has installed the User Identification Client (software that runs on the 
user's machine and provides identification information about the user to access 
filter 203). 
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make administrative policy for the information set, and vice-versa. When an access filter 
203 is first set up, a single built-in security officer user group has administrative authority 
over all of the objects in VPN 201 and over policy maker policy 306. 

5 Inheritance with administrative policy 

Inheritance works with administrative policy the same way that it does with access policy. 
The user groups, information sets, and available resources to which administrative policies 
are directed are hierarchically organized: Within the user groups, user groups that are 
subsets of a given user group are at the next level down in the hierarchy of user groups 

10 from the given user group. The same is the case with information sets. Inheritance 
applies within the hierarchy in the same fashion as with access policy. Thus, within the 
user group hierarchy an administrative user who controls a user group also controls all 
subsidiary, contained user groups. Similarly, with the information set hierarchy an 
administrative user who controls the information set also controls all subsidiary, contained 

15 information sets and an administrative user who controls access policy for an information 
set also controls access policy for all contained information sets. 

There is further a natural hierarchy of available resources. For example, one level of the 
hierarchy is locations. Within a given location, the servers at that location form the next 

20 level down, and within a server, the services offered by the service form the next level. 
The administrative user group that has control of any level of the available resources tree 
also controls ail lower levels. For example, the administrator(s) to whom an administrative 
policy gives control of an access filter 203 has administrative rights to all servers beneath 
that site, all services running on those servers and all resources supported by those 

25 services. 


Delegation: FIG. 25 

Delegation is easy in VPN 201 because the members of the administrative user group that 
administers an object may both modify the object and make administrative policy for it. 
30 For example, if an administrative user group administers an information set, it can divide 
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Security Officer . 2503 of course still has administrative authority over 
Engineering Administrators and can use that authority for further delegation. 
An example is shown at 2517, A member of Security Officer 2503 has divided 
5 Engineering Administrators into two subsets: Engineering Personnel 
Administrators (EPA) 2519 and Engineering Data Administrators 
(EDA) 2521. The members of these subsets inherit administrative rights over 
Engineers 2511 and Engineering Data 2513 from Engineering 
Administrators 2509. The members of EPA 2519 and EDA 2521 use these 

10 administrative rights to delegate administrative authority over Engineers 2511 to 
Engineering Personnel Administrators 2519 and administrative authority 
over Engineering Data 2513 to Engineering Data Administrators 
2521. The members of EPA 2519 and EDA 2521 have further used their right to make 
access policy for Engineering* Data 251 3 to change the access policy so that access 

15 policy for Engineering Data is made by Engineering Data 
Administrators 2513, as shown by dotted arrow 2523, instead of by 

Engineering Administrators, thereby delegating that function to 

Engineering Data Administrators. 

20 Members of Engineering Personnel Administrators and 
Engineering Data Administrators can now use their administrative rights 
over Engineers, Engineering Data, and access policy for Engineering 
Data to refine access to Engineering Data. For example, a member of 
Engineering Personnel Administrators might subdivide Engineers 

25 into Software Engineers and Hardware Engineers and a member of 
Engineering Data Administrators might subdivide Engineering Data 

4 

into Hardware Engineering Data and Software Engineering Data. 
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an access filter 203 observes an attempt by a user to initiate a session with a service, it 
determines whether access should be permitted. It does so from the known identity of the 
user, the information resource to which the information is being accessed, the sensitivity 
level of the information, and the trust levels of the user identification, of the path between 
5 the user and the service, and of any encryption technique used. . . 

FIG. 4 shows how a session can involve more than one access filter 203. Session 402 
shown in FIG. 4 involves five access filters 203, numbered 403(1.. 5) in the Figure. 
Access filters 203 are designed such that the decision whether to grant a user access to an 

10 information resource need only be made in one of the access filters 203. The key to this 
feature of access filters 203 is their ability to authenticate themselves to each other. SKIP 
is used to do this. Every access filter 203 has an X.509 certificate that binds the access 
filter 203's keys to the access filter's name and is signed by the Certificate Authority for 
the VPN. Each access filter 203 has the names and IP addresses of all of the other access 

15 filters in VPN 201 in data base 301, and upon arrival of a session that is encrypted using 
SKIP, each access filter uses the Subject Name from the certificates as described above in 
the discussion of SKIP to determine whether SKIP-encrypted network traffic is from 
another access filter 203 in VPN 20 1 . 

20 If the access filter receiving the session is not the destination of the session, (that is, the 
access filter functions simply as an IP router along the path), the access filter merely 
verifies from data base 301 that the destination IP address is the IP address of some other 
access filter 203 in VPN 201. If that is the case, then the session is allowed to pass 
without additional checking. When the request reaches the last access filter 203, the last 

25 access filter 203 uses SKIP to decrypt the request, to confirm that the request was indeed 
checked by the first access filter 203, and to confirm that the request has not been 
modified in transit. 

Thus, in FIG. 4, access filter 403(1) uses its own copy of access control database 301 to 
30 determine whether the user who originates a session has access to the information resource 
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FIG. 5 shows how this is accomplished using access filters 203. Within the VPN, 
authentication and encryption may be used with any cHent system 401 or 503 or any 
server system 407 in addition to access filters 203. When a client computer utilizes 
encryption^ it uses SKIP to authenticate the session and encrypt it using a shared secret 
5 that is shared between the client computer and a selected access filter 203 and then sends 
the encrypted message to the selected access filter 203, thereby effectively establishing a 
tunnel between the client and the selected access filter 203 and making the selected access 
filter 203 the first access filter 203 for purposes of access checking. At the first access 
filter 203, the messages are decrypted and access checking is done. Since SKIP makes 

10 available the user's certificate along with the encrypted message, the user's authenticated 
identity can be used for access checking. If the access is permitted, the message is once 
again encrypted and sent to access filter 403(5) nearest server 407, which decrypts it. If 
data base. 301 contains a SKIP name and encryption algorithms for server 407, access 
filter 403(5) retrieves the certificate for server 407 if necessary and uses SKIP to reencrypt 

15 the session as required for server 407. Otherwise, access filter 403(5) simply sends the 
message to server 407 in the clear. If the message was reencrypted for server 407, server 
407, finally, receives the encrypted message and decrypts it. The access filters 203 
intermediate to the first access filter 203 and last access filter 203 simply note that the 
message is from another access filter and is encrypted with SKIP and pass the message on, 

20 as described above. When server 407 retrieves the information resource, it either sends it 
in the clear to access filter 403(5) or encrypts the message containing the resource with the 
key for access filter 403(5). The process of decrypting and encrypting described above is 
then performed in reverse, pairwise, from server 407 to access filter 403(5), from access 
filter 403(5) to access filter 403(1), and finally fi-om access filter 403(1) to the original 

25 client system, which decrypts it. 

The effect of this technique is to construct a tunnel on the path between the client and the 
server which runs from the access filter 203 on the path which is nearest to the client to 
the access filter 203 on the path which is nearest to the server. If the client is capable of 
30 encryption and decryption, the tunnel can be extended from the access filter nearest the 
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collectively termed SEND (Secure Encrypted Network Delivery). In SEND, access 
control database 301 contains a data sensitivity level for each information resource. The 
data sensitivity level indicates the level of secrecy associated with the information 
resource and is assigned to the information resource by the security administrator 
5 responsible for the resource. An exemplary set of levels is Top Secret, Secret, Private, and 
Public. 

The levels used to indicate data sensitivity are also used to indicate the trust level required 
for the access request. As previously described, access will be permitted only if the trust 

10 level determined from the trust level of the technique used to identify the user, the trust 
level of the path of the access request through VPN 201 or the trust level of any 
encryption technique used to encrypt messages sent over the path is at least as great as the 
data sensitivity level for the information. The trust levels for user identifications, paths, 
and encryption algorithms are contained in access control database 301. With regard to 

15 trust levels of paths, the VPN is divided into network components^ each network 
component being a connected set of IP networks that is separated from other components 
by access filters 203. Each network component has a name and a trust level. For 
example, an Internet component will have the Public trust level, while an internal network 
component may have the Private trust level. The trust level of a given component may be 

20 based on its physical security or on the use of encryption hardware in the component. As 
each access filter 203 is added to a VPN, a description of its connections to the 
components of the VPN is added to database 301. Included in this description are the trust 
levels of the networks. Consequently, any access filter 203 can use its copy of database 
301 to determine the trust level of each component of the path by which a session will be 

25 carried between a client and a server. 

■ • 

The trust level for a user is determined from the manner in which the access request 
identifies the user. In access control database 301, each group of users has one or more 
identification techniques associated with it, and each identification technique has a 
30 minimum trust level. The basic techniques are: 
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• «i^iP A user is identified by the name in his or her X.509 
Certificate via SKIP. A user is m 

certificate used with the SKIP protocol to authenticate and encrypt traffic. 
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Microsoft Windows Domain and has installed the User weni 
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cryptographic algorithms and orders the network paths employed in VPN 201 and relates 
the ordered trust levels to the ordered network paths. These relationships between trust 
levels and orderings with regard to security are included in access control database 301. 
Then a SEND table is constructed which relates trust and sensitivity levels to 
5 identification and encryption techniques. FIG. 6 is. a conceptual representation of such a 
SEND table. 

SEND table 601 has three columns: one, 603 for the trust/sensitivity levels, one, 605, for 
minimum encryption methods, and one, 607, for minimum identification methods. For 

10 details on the encryption methods of column 605, see Bruce Schneier, Applied 
Cryptography, John Wiley & Sons, New York, 1994. Each row 609 of the table 
associates a trust/sensitivity level with a minimum encryption level for the path 
connecting the access filter, client, and server and a. minimum identification level for the 
user. Thus, row 609(1) associates the "top secret" trust/sensitivity level with the 3DES 

15 encryption algorithm and a user certificate obtained via SKIP. A user who wishes to gain 
access to a resource with the sensitivity level "top secret" must consequently have an 
identification that is certified by SKIP and if the path does not have a "top secret" trust 
level, the session must be encrypted with the 3DES algorithm. On the other hand, as 
shown by row 609(4), a user who wishes to gain access to a resource with the sensitivity 

20 level "public" may be identified by any method and there is no requirement that the 
session be encrypted. 

When a new session is initiated, the first access filter 203 in the path employed for the 
session proceeds as follows: 
25 1. The access filter determines the information, resource being accessed and looks up 

its sensitivity level in database ^Ol. 
2. The minimum authentication for that sensitivity level from SEND table 601 
specifies which identification mechanisms may be used by the access filter to 
identify and authenticate the user making the access. 
30 3. The first access filter 203 then consults database 301 to determine fi-om the user 

■ 
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segment (c) will not exist if the server is on the access filter nearest the server. If 
segment (b) exists, it will consist of one or more network components. Segment 
(b) will not exist if there is only one access filter between the client and server. 
5. For each of the segments: 
5 a. For segment (a), any encryption must be done by the client. If the trust 

level of segment(a) is not at least as strong as the sensitivity of he resource, 
or if the trust level of the encryption done by the client is not at least as 
strong as the sensitivity of the resource, access is denied. 

b. For segment (b), if the weakest trust level of any network component in the 
10 path is greater than or equal to the data sensitivity of the resource, then the 

traffic is sent without encryption. This corresponds to the case where the 
network is inherently secure enough to transmit the data. In the example 
table above, inforrnation resources with a Public data sensitivity level may 
be transmitted on any network, as shown by row 609(4). However, the 

15 access filters 203 will use SKIP to authenticate the session, allowing 

subsequent access filters to pass the session through without incurring the 
larger overheads of decryption, access checking, and reencryption. If the 
weakest trust level for the path is less than the data sensitivity of the 
resource, then the SEND table is consulted for the minimum encryption 

20 algorithm required for the sensitivity level and the session is encrypted 

using that algorithm. The encryption upgrades the security of the link, 
making it suitable to carry data of that given sensitivity and permitting 
access by the user to the resource. 

c. For segment (c), the portion of the path from the access filter 203 nearest 
25 the server to the server, first access filter 203 determines the trust levels of 

" segment (c) and of any encryption used in segment (c) from information 

in database 301 . If the trust level of this segment of the path is less than the 
sensitivity level of the information resource, and in that case, if the 
encryption used in segment(c) is not at least as strong as that required as 
30 the minimum level in the SEND table considering the sensitivity level of 
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irralbase to detennine the sensitivity level of resource 723. Here, the user has used 
SK^I^^ an- an e^ination of SEND table 60. in data base 30. shows access 
flUe? 0^r« >^"- of user identification meets the requirements for i— 
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access filter 203(1) accordingly encrypts the session using that algorithm and sends it to 
access filter 203(5). 

In FIG, 7, segment 707 connecting client 703 to access filter 203(1) has a trust level which 
5 is high enough for the resource's sensitivity level, and there is thus no need for client 703 
to encrypt its request. When that is not the case, access filter 203(1) will give client 703 
access only if client 703 has encrypted the request using an encryption method whose trust 
level is sufficient for the sensitivity level of the resource. It is for this reason that roamer 
503 in FIG. 5 must be SKIP-equipped. Since roamer 503 accesses access filter 403(3) via 

10 Internet 121, roamer 503's requests can never have more than the public trust level unless 
they are encrypted, and in order to have full access to the resources in VPN 201, roamer 
503 must uise ari encryption method such as the one provided by SKIP whose trust level is 
sufficient for the highest sensitivity levels. In some embodiments of access filter 203, the 
access filter may negotiate the encryption technique to be used in a request with the client 

15 in a manner similar to that which it employs in the preferred embodiment to negotiate the 
user identification mode. 

Overview of the AdministratorsMnterface to Access Control Database 301: FIGs, 8- 
12 

20 An access policy defines access in terms of user groups and information sets; consequently, 
before an access policy may be defined, the administrators must define the user groups and 
information sets; how that is done is shown in FIG. 8. Defining a user group involves steps 
803 through 807: first the users are defined, then the user groups are defined, and then the 
users are assigned to the proper user groups. Defining information sets involves steps 809 

25 through 813: first the resources are defined, then the information sets are defined, and then 
the resources are assigned to the information sets. When this has been done for the user 
group and information set involved in a policy, the access policy can be created, as shown 
at 815. As previously pointed out, the rights to define and determine the membership of 
user groups and information sets and to make administrative policy for them are 
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determined by the administrative policy, while the right to make access policy for user 
groups and information sets arc determined by the policy maker policy. 

As can be seen from the foregoing, the user interface is generally used to define 
relationships between two entities or sets thereof. The general form of the graphical user 
interface (GUI) for access control database 301 corresponds to that task. The display 
includes two windows, each of which contains representations of entities that are to be 
brought into relationship with each other, and the relationship is defined by selecting the 
entities and where necessary, defining the relationship. 

Defining User Groups: FIG. 9 ^ 
FIG 9 shows the display 901 for populating and defining user groups. Window 903 m the 
display contains a hierarchical display of currently-defined user groups; window 903 is 
similar to those used to display hierarchies of files in the Windows 95 brand operatmg 
system manufactured by Microsoft Corporation. In window 903, user groups for which the 
administrative user using display 901 has administrative rights appear in black; the other 
user groups appear in gray. Above the two windows are two button bars 91 1 and 915. 
Button bar 91 1 lists the displays available for modifying access control database 301. while 
button bar 915 lists the operations that may be performed on those displays. Thus, the 
button label "user groups" in button bar 911 is highlighted, indicating that display 901 is 
the one for populating and defining user groups. With regard to button bar 915. when 
window 903 is active, an administrative user with the right to administer a user group may 
„,odify the user group by selecting it in window 903 and using the delete button m button 
bar 915 to delete the user group or the ne^ button to add and name a new user group that 

tVio hif>mrchv When the administrative user clicks on 
is beneath the selected user group m the hierarchy, wnen mc <x 

apply button 921, access filter 203 modifies its copy of access control database 301 to 
conform with what is on display 901 and the modifications are propagated to all copies of 
access control database 301 in the VPN. 
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Window 909 displays users. A set of user is indicated in the display by the manner In 
which the user in the set identified. In this case, the users are identified by IP addresses 
and they appear in the display as ranges of IP addresses. Button bar 913 indicates the 
other kinds of identifications that can be displayed in window 909. As with window 903, 
5 when the window is active, the new and delete buttons can be used to add and delete users. 
To assign the user(s) specified by a user identification to a user group, the user of the GUI 
selects a user group, as shown at 917, and a set of identifications, as shown at 919, and then 
uses the add to group button in button bar 91 3 to add the set of identifications to the group, 
as is shown by the fact that the range of IP addresses selected at 919 now appears in the 
10 hierarchy below the user group selected at 91 7. The effect of the operation is to make users 
whose sessions have the source IP addresses listed at 917 into members of the user group 
R&D, and when the user clicks on the apply button, all copies of access control database 
301 are modified accordingly. 

15 FIG. 10 shows the display 1001 used to define information sets. Here, window 1003 
contains a hierarchical list of information sets and window lOOS contains a hierarchical list 
of the available resources. The hierarchical list of information sets and the hierarchical list 
of available user groups made in the same fashion as the list of user groups. Again, 
information sets and available resources over which the user of display 1001 has 

20 administrative authority appear in black; the other items on the list appear in gray. In 
window 1001,- the available resources are the Internet and the two locations that make up 
VPN 201. In a more developed VPN 201, the list of available resources would indicate 
servers at the location, services in the servers, and the information items provided by the 
services. For example, if the service provides a directory tree, the information items 

25 contained in the directory tree would be indicated by means of a pathname which specified 
the root of the directory tree and used wildcard characters to specify the files above the 
root in the tree. When a resource is added to a server, the resource may be defined via the 
1005 window. Having thus been defined, a resource may be assigned to an information set 
in the same fashion that a user identification is assigned to a user group. Again, clicking on 
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a,e appfy button causes *e cha„g« ta display 1001 to b. p~paga.ed .0 all copies of access 
control database 301. 

F,G U Shows*, display 1101 used u- define policies. Which We of policy is being 
defined is specified in button b. U 1 3; as indicated U,ere. display "^O";^^ 
policy. All of d,e policy displays have d,e same general fonnat: a w,ndow 1 103 wh, h 
con Jns a hierarchical display of use, groups, a window 1 ,05 which contains a d.pUy of 
hierarchy of objects for which policy n,ay be defined and a policy defimtton w,ndow 1 107 
which con«ins access policy definiUons l.OS. In .he hierarchy of '^'^'^^^^^ 
which *e user of display UO. has *e right to define policies appear ,n black, the others 
appear in gray. In display 1 .01. wtat is being defined is access policies so the objecU are 
information sets. 


Each access policy definition has four parts: . 
,5 . an active check box 1 1 17 that indicates whether the access pohcy defined by the 

definition is active, i.e., being used to control access; 
the user group 1 1 19 for which the access policy is being defined; 
. the information set 1123 for which the access policy is being defined; and 

. access field 1121, which indicates whether access is being allowed or denied and 
on thereby defines the access policy. 

Menu b. . 1 09 and button tar U 1 5 pe^it administrators whom the policy maker pol.cy 
Tws to do so to edit, add. delete, .d activate or deacUvate a selected policy defimt.on 
r Active Check box .117 of each policy definition 1.08 permits the admm,stra»r to 
I vate or deactivate the selected policy definition UOS; accesa field .12. perm.ts *e 
. allistrator to select either ^/ow or as the policy. The button m button bar 
uTrpermits the administrator to delete a selected policy; the button permtts ^ 
LminLator to make a new policy deflnidon 1 lOS; to do this, the administtatt>r selects a 
Z group in Window 1 10, and an information set in window 1 .05 and ,h» pu*. * 
Lon. The new access policy definition UOS appears <"^P'^^ * 
30 administrator can edit the new access policy definition as just descnbed. To apply 
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' change to access control database 301 and propagate it to all access filters 203, the 
administrator clicks on apply button 1 125. 

Display 1101 also contains a policy evaluator tool which lets the administrator see how the 
5 current set of access policy definitions determines access for a given user group or resource 
set. When the administrator clicks on the policy evaluation button in button bar 1113 and 
selects a user group from display 1 103, the tool displays the selected user group in blue and 
all of the information sets in display II OS which the policy definitions permit the user 
group to access in green and the remainder in red; all of the policy definitions which are 

10 relevant to the determination of which information sets may be accessed by the user group 
are highlighted in the same set of colors. The same thing happens if the administrator 
selects an information set; then the evaluator tool displays the selected information set in 
blue, all of the user groups that can access the information set in green and the rest in red, 
and also highlights the relevant policy definitions. The user can also select a policy. In 

15 that case, the selected policy appears in blue and the user groups and information sets 
affected by the policy in appear in blue or red, as determined by the policy. The user can 
additionally select more than one user group, information set, or policy. In that case, the 
evaluator tool shows each policy that applies to all of the selected items and the effects of 
those policies. The evaluator tool can be turned off by clicking on policy evaluation in 

20 button bar 1113 and colors and highlights can be turned off in preparation for a new policy 
evaluation by clicking on the reset evaluation button in button bar 1115. 

FIG. 12 shows the display 1201 used to input information about an access filter 203 to 
access control database 301. Window 1203 shows a hierarchical list of the access filters 

25 203; when the window is active, access filters may be added or deleted using the add and, 
delete buttons in button bar 1209. Window 1205 is used to input or display information 
about the access filter 203. The display in window 1207 is determined by clicking on a 
button in button bar 1207; as shown by the buttons, displays in window 1207 can be used 
to input and view information about access filter 203 's network connections, to input and 

30 view information about the trust levels of those connections, to scan networks for available 
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. »d service, .o se. up alens for problem, detected to access filter 203. to specify 
T„C™for softl, and to specif *e distribution order of »=cess cont.1 

m Hisbli^tin, of .e„ indicates .Hat display U03 sHown .„ 
FIG. 12 is the display used to display and establish alerts. 

' :r"rr:ir:r::r:rurcesa.ca.iia. 

r ;i THe interface, termed Kerein ^ ..ra^P interface isa — 

!f internet Dynamics, Urcorporated), shows each user a. leas, the resources ,h« be^^ 
: nfomration sets that the user may access according to the access P*- ~ 
sets the user belongs to. In other embodiments, ^ IntraMap may take . e so^^^rn 
sets identification into account as well, 

level of the resource and the trust level oi me u» 

r « fo^a^'^ annlet that runs on any 
The IntraMap interface is implemented by means of a Java applet 

ed World Wide web browser. Using the Web browser, the user can scan the 
Java-equipped World W.de W ^^^^ ^^^^^^^ 

graphical display to find and access resources that are^ava. ^ ^^^^ ^ 

access to resources that are not currently available to the user. Acce 

. • hv the access policies that apply to the user and the resource. FIG. 
resource .s determmed by the access po. W ^.^^ 

,S Shows the display ISOl produced by ^^^^^^^^^^ 
IntraMap display 1801 shows a Resource Ust 1803 the nght 

p «H field 1807 a Sort section 1809. a Services section 181 U ana a 
;ri:n.r:lth:forusin.*eh.traMapisavai,^^^^ 

aesource Ust 1S03 shows r=.urces and infonnation av..able ™- 
Who is usins .he .n-raMap in.^.^. The ^^^^ - ^ brlches, 
collapse branches of the W by ^^ed to display an 

^ entry .S04 in the lis. includes a name for the — . ^ 

entry indicates what ^nd of access user ha. 't*' ' ' „ 

^ has an active hyperlinK to .He resource at-d ^^^^'^^^ bu, no hyperlink is 
, i. displayed. If it is displayed in black, U is also avatlablc «> the user. 
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available, so a separate application must be used to retrieve it. Resources displayed in 
gray are not directly available to the user, but if the user selects one, the IntraMap 
interface opens a dialog box that permits the user to send email requesting access to the 
administrator who is responsible for access policy for the information set the resource 
5 belongs to. The administrator may then modify the access and/or administrative policies 
as required to give the user access. An administrator may further give a resource the 
hidden property. When a resource has that property, it will appear in IntraMap interface 
1801 only if the user belongs to a user group that the access policies permit to have access 
to an information set that the resource belongs to. If a resource does not have the hidden 
10 property, it will always appear in IntraMap interface 1801. Otherwise, it does not appear. 
A resource may have a more detailed description than that contained in its entry 1804. 
The description is displayed in Description field 1813 when the user selects the resource. 

» 

15 In addition to.resource list 1803, IntraMap display 1801 displays two. specialized resource 
lists at 1805. ' 

• What's New 1806 displays the latest information postings from others within the 
enterprise. If an administrator has given the user access to the What's New web 
page, the user may post the URL of a new resource there. 
20 • What's Hot 1808 displays the enterprise's most popular information resources, 

based on how frequently they are accessed. 

The service types control at 1811 lets the user filter the resources that are to be displayed 
in resource list 1 803 by the type of service that provides the resource. Each service type 
25 has a check box in service type control 1811. If the box is checked, the service type is 
included and the resources associated with this service appear in the Resource List. 
Otherwise, the resources associated 
with this service do not appear in the Resource List. 
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. -.rf^. lets the user sort Resource List 1803 by information sets. 
The IntraMap interface lets the user 

T« Ho this the user selects the way he or she wisnes 
,ocaUo„. o. sen,,^^. TO do *,s. ^ ^ ^ ^^^^ „^ 

.sou^ U. .n 2 in^rface funher has a search ««.ion. To do a 

categories are used m the sort. 1 he The resource list and the 

^H. the use, enters a search stnn, '■', '^l^'^^^2-,n^^„,^,,^.„.o. 
resource descriptions for the resources on ,t are then setuched m 
r.,d ,809. The search si.p.y .ooi. for whoie or parua, wor^ 
«„.«,e. The firs. ™atch is displayed, and funct.on .eys - » , 
^ Of course, if a user has not checked a serv,ce type >n serv^ type 

r:!l ofthat service type are not invoWed in either sorting or searchtng. 

..„s an i.— .0. Of the^^aMap in..a.^ Jo the u.^^^^^ 

report manager 209 running ^^j, ^ 

the general public (that is. someone who ,s a 
,.en access to the .tra^.p in«rfa« n ^ 

o al serve, . VP^ ... .^P— «0, has 
page for „^ „ ,o„k at the IntraMap. components ,n 

components m vrarkstatton 2403 use y ^^^.^^^ 

n. in-j/i> »;hich is local to work station 24U I . ana in 
. access Alter 2 3^ wh^ h . ^ ,„3,,, 

is the acc^s ">»"J^ ^ ^^^^ ^,,^3 2030) is connected to report 
may also functton as a local access 1. j.,^^^ 
access filter 203(c) by VPN 201 and workstation 2403 is connect 


203(1) by LAN 213, 


25 


30 


. be e^plalned in more detail - ^ 

— rirrTrrr 1 addresses m .temet packet 

"T' TI ra - riles to them, .s determined by the rule, it either accepts 
headers and applies a set ot The rules also determine how the 

them, discards them, or routes them farther m VPN 20 1 . 
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accepted packets are to be routed within access filter 203. The next layer of the 
architecture is service proxies 2427. The service proxies intercept traffic for services 
such as the World Wide Web and do access checking on the traffic. If access filter 203 
provides the service itself or does access checking for a server that provides the service, 
5 IP filter 2419 sends packets intended for the service to a service proxy 2427 for the 
, service. The service proxy uses access control database 301 to do protocol-level access 
checking for the service. For example,* the service proxy for the Web service may check 
whether the user making a request for a given Web page has access rights for the page. 
The next higher level is services level 2425; if the relevant service proxy permits an access 

10 request and the access filter is also the server for the service, the request goes to the 
service at service level 2425 to be processed. In the case of the Web page, the service 
would locate the page and return it to the requestor. Two services are involved in the 
IntraMap: the Web service and an IntraMap service. In FIG. 2401, the Web service 
appears as WebS 2423. The proxy for WebS 2423 is WebP 2421; for reasons that will 

15 become clear in the following, the IntraMap service has only a proxy, IntraMapP 2417. 
Additionally, access control database 301 includes IntraMap information 2422, which is 
an optimized version of the information in access control data base 301 that serves as a 
basis for the IntraMap display. 

20 The chief difference with regard to the IntraMap implementation between access filter 
203(c) and access filter 203(1) is that access filter 203(c) includes a World Wide Web page 
2410 with a copy of IntraMap Java applet 2411. When downloaded from access filter 
203(1) to Web client 2429 in work station 2403, Java applet 2411 produces requests 
directed to IntraMap server 2425 and uses the results returned by IntraMap server 2425 to 

25 produce IntraMap display 1 80 1 . 

Operation is as follows: to the user of work station 2403, the IntraMap may appear as a 
link to a Web page. Thus, to use the IntraMap, the user activates a link to IntraMap page 
2410. Web browser 2429 in workstation 2403 responds to the activation of the link as it 
30 would to the activation of any other link to a Web page: it makes a request for the page 
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and sends i. io .he server indicated in tl,e link. In .he case of Ae link .o 0« InttaMap, *e 
link specifies Web server 2423 in access fito 203(c), so .he re,ues, goes via local access 
filter 203(1) and VPN 201 .o access fite 203(c). As w,.h any oAer access K, a resource 
in VP 201 local access fiter 203(1) does access checking tor Ae InttaMap page request. 
Since the Request is for a Web page, the checking is done by Web proxy 2421. In ntos. 
VPNS 201, IntraMap page 24.0 will be accessible to any user in VPN 201, and access 
control data base 301 thus indicates that any user wiU, a valid IP source address nuty 
access IntraMap page 2410, 

When the truest is received in access fito 203(c), IP filter 2419 forwards it to Web 
p,.xy 2421, Which in turn forwards it to Web server 2423. which responds to the r^ue. 
by downloading lnt«Map applet 241 1 to Web browser 2429 in work statton 2403, where 
InttaMap apple. 24. 1 begins execufing in Web browser 2429. During execufion, ,. sends a 
reques, .o m.raMap proxy 2427 for IntraMap information 2422. Like all Java applets, 
IntraMap apple. 24. , sends the request to the setver that it is residem on, ,n *,s case 
access fi.t« 203(c). However, as with »y other request from 
request goes by way of local access filter 203(.). There, IntraMap proxy 2427 detects Utat 
request go<» , .> .„es. filter 203(c) and instead of 

the request is addressed to IntraMap proxy 2427 m access filter ( 
sending the reques, on to access filter 203(c). obtains InUaMap informatton 2422 from the 
:ripy of access con«ol dau base 30. in local access filter 203(1), filters it so that .t 
.p..fies only those resources belonging to the infomtation se. to which the us. ^ups 
. which the user belongs have access to make to list 243. and returns >. v,a 213 » 
IntraMap apple. 2411, which Uten uses list 2431 to make IntraMap ^'^^^^^^ ^ 
making the display, applet 241. applies any filters specified m the request and also so^ 
. d.. J as specified in the tequest. ^« ' ^ ""'^ " 

available, but also contains information needed to fetch the resource. Thus. ,f the ,^ou^ 
bas a hyperlink, the hyperlink is included in tite list; if it is a .^urce for wh.ch the us^ 
presentMoes not have access, but .o which .he user may request access, the hs. mcludes 
the name and email address of the administrator for the resource. 


30 
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Details of Access Control Database 301: FIGs: 13-17 

In a preferred embodiment of access filter 203, access control database 301 is 
5 implemented at two levels: one used by the graphical user interfaces use to manipulate 
access control database 301 and another used in actual access checking. The first level is 
implemented using the Microsoft Jet brand database system developed by Microsoft 
Corporation. The second is implemented using memory mapped files (MMFs) which are 
compiled from the first-level data base. The following discussion will describe the first- 
10 level implementation and explain how the information contained in it is used in access 
checking. In reading this discussion; it should be remembered that actual access checking 
. is done using the MMFs, as will be described in detail later. 

As is the case \yith most database systems, the Microsoft: Jet brand database system has a 

* 

15 schema^ that is, a description of the logical structure of the database. FIGs. 13-17 are 
displays generated by the Microsoft Jet brand database system of the schema for access 
control database 301. FIG. 13 shows the schema 1301 for the part of the database that 
defines user groups. The display is made up of two elements: representations of classes 
of tables 1303 in the database and representations of links 1305, which show relationships 

20 between tables belonging to certain classes of tables. The representation of the class of 
the table shows the name of the class at 1310 and the data fields that will be contained in 
each table belonging to the class at 1308. Each table instance has an ID assigned by the 
database system. The other data in the table varies with the class of table. A link is 
made between a first table belonging to the first class of tables and a second table 

25 belonging to the second class of tables by using the ID of the second table in the first 
table and vice-versa. Thus, link 1305 shows that tables of the class User Group Tree table 
1307 can be linked with tables of the class User Groups table 1309. Some links have 

m 

numbers at their ends. The numbers indicate the number of the links that the table at the 
end the number is located at may have. Thus, the link connecting the table of class 1309 
30 and the table of class 1307 has the number 1 at the end for the table of class 1309 and the 
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K .t the end for the table of class 1307. indicating that any number of IDs of 
:m n,. appe. . . .s^ce o. Ca. ,30,, on. . . ^ 
instance of class 1307 may appear in an instance of class 1309. 


User Group Tables: FIG. 13 ^^^p 

user group tables 1301 contams a table of cl^ g P 

. u nata of particular interest in tables of class t/serorowp^ 1^ 

database 301 . Data ot panic description, which 

xvhirh is the character-string name of the group, mc giu 
group name, wh.ch .s ch „e-defmed infomiation, which indicates 

•o , ^Karacter-strine description of the group, ana pre ucx 

,s a character string u y „^rr.i^r nf \hs sxonv is an administrator, uc., 

^fh^r thinas whether a user who is a member ot the group 
among other things whetn ^^^^ ^ 

can make administrative policy, a ..c«n/y officer, i.e., can m p y 

f nfom^ation User group tables 1301 fiirther organizes the user groups 
simple user of information. User gr J ^^.^^^^^,^,,1 display of 

a hierarchy - both for the purposes of inheritance ana ai!,o 

a hierarchy ^^^^i^t, identifications of users with the 

user groups shown m window 903 of FIG. 9. the hierarchy 

user groups, and associate alerts with the user groups. The orga ^^^^^ 

Hst is done by means of tables of class User Grou, ^ " 
... aro^ Tree linlcs a table of the class Vser ^^^^^ f ,,,, 
G«,M>> MulUple User Group Tree tables may exist lor p 

*! ^ „f „,^, in which a particular user group appears. 
C?TOi/f. table, depending on the r.uinl>er of places mwmc p 

■ ^,y,^«c five different ways of identifying users to an access filter 
alteady ^ a U.-alified .temet don^in nante, by the identity 

' ' '"I M crtr~s btld operating system, by an authen.ica.on toKen. 
„f *e user tn the ^ „ i,,„,^ „^ by certificates a« 

r r r l cLses fo, .he taUes that identic users by a range of IP 

, shown as 132U The tab .^^^.^ ^ ^ ^ 

T'^: Z 1 *a. identify users by Windows brand operating systen, 

*own a. 1 19. those fo ^^^^ ^„^^,^,„„ 

ID'S ate shown at 1315, ana inose ^^^^ 

u rl^heled as smart card in the figure) are shown at 1323. The tame 
mkens (labeled as sraari i." , . , _ ,u„ related to user groups. A 

, finally, define tables for *e infom«tion used m alerts that are related .o 
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table of User Group class 1309 may have associated with it any number of tables for any 
of the ways of identifying users. As this implies, a given user may be identified in a 
number of different ways at once. 

5 In order to perform a^n access check, access filter 203 must determine what user groups the 
user making the request belongs to. The request includes an identification for the user, 
and the identification is the starting point for the determination. The tables in user group 
tables 1301 permit access filter 203 to determine from the identification what user groups 
the user belongs to and from those user groups, the hierarchical relations that determine 
10 the other user groups the user belongs to. Assuming that the user is identified by an IP 
address, access filter 203 begins by finding one or more tables of the IP Range Definition 
class (in 1317) which define ranges of IP addresses which include the user's IP address. 
Each of these tables has a link to a table of the IP Ranges class (in 1 3 1 7) which relates the 
range defined in the IP Range Definition class table to a user group ID, which in turn 

15 serves as a link to*a table of class User Groups 1309 for the user group corresponding to 
the range of IP addresses. Each of the tables of class User Group has a link to a table of 
class User Group Trees, from which links can be followed to the tables of class User 
Groups for the user groups from which the user groups specified by the IP addresses 
inherit access rights. Thus, at the end of the process, IP filter 203 has located all of the 

20 user groups which are relevant for determining whether the user may access the resource. 
Moreover, IP filter 203 knows frorri the request how the user is identified and can 
determine from that what level should be assigned to the identification of the user used in 
the request. The information in user group tables 1301 is compiled into. MMFs. When a 
user initiates a session, the user provides a user identification to the first access filter 203 

25 on the session's path; access filter 203 uses the user identification with the MMFs to make 
a determination equivalent to the one explained above. Access filter 203 can thus 
determine for a given user identification whether it identifies a user that has access, what 
kind of user identification it is, and therefore what trust level it has, and which user groups 
the user belongs to. User group tables 1301 thus contain all of the information needed for 

30 the user portion of an access policy 1 108. 
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H t., the network locations of the resources and also organize ine i 
K-e— Hs. Of .f<,™a.o„ se. .spUyea a. ,00, of F.O. .0. Each .n~ 
Z ntL co„«. ^ 30, is represcnud by a ab,e o, c,« ™ ^o^^^^ 
Tl^Z resource ^ organized in. a hie««hy for i„heri«„ce and d.pia, 
" ^ 1 ^ ,4,9. — ip be,««n an info™a.io. s« and U,c — 

utrn on. hand and ^ iocaUon. in *e VPN in »hioh a. sured a,, 
that make It up on one n<u , ,.^7 a table of class rewce 

.«ab,i*ed by ub,ea of oiass resource poup ele^n^ ,407, uMe o 

n,ay be .inKed .0 any nun^ of «b,.s " c,L 

1/111 c^KviV^^v 1413 and Resources 1409. mere is> a tau 

f„ every ^^^'^ ^^^^^ ^„ ^ ^ fo, a defini.on of *c resouroc-s 

di; oT^f ~ d.e cn-ai, add.as of *e adn.inis»a«,r of .he 

: a^T ; rflag Which indica.cs whc*er ,n«3Map should display *c resource 
resource and a huklen g 1^,^^ 
„ users who do no, belong «. user groups to. have access .0 
in^rfacc obrains a,e informa.ion i< needs abou. a resource from *e Reso^ 


the resource. 


25 


, r, . «/*.n those of the classes Sites 
Th. tables of the classes Site Elements and Services, as well as those oi 
The tables 01 mc vioa that describe the locations of 

- 1417 helone to the classes 1421 that aescrioe 
1415 and Servers 1417 belong to ,,,,,,, for every physical location in the 

• *u \/p>j There is a table of class Sites tor every vuy 
information in the VPN. There is a la 

- ^ "^^--rir r« oTciass ...... 

'^2. IZZ-l Ubles Of Class S^^ces re,a.e .he services » to resources to. 


30 they host, 
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In determining what information sets a requested resource belongs to, access filter 203 

* 

begins with the information in the request. The request is contained in an IP packet, and 
consequently has a header and a body. In the header there is an IP address which 
5 specifies a location in virtual network 201 and a server at the location, a port number 
which specifies a service on the server, and in the body, the description of the resource in 
the form prescribed by the protocol. For example, if the request is for a Web page, the 
description of the resource will be the resource's URL. Access filter 203 uses the IP 
address to locate a table of class Sites , uses the link in that table to locate a table of class 

10 Site Elements 1411. That table relates the site to the server IDS for the servers at the site 
and access filter 203 uses the server IDS to locate the tables of class Servers 1417 for the 
site's servers. It can then use the IP address again to locate the table of class Servers 
corresponding to the sierver specified in the request and can follow the links from the 
Server table to the tables of class Services for the service and can use the port number 

15 from the request to find the proper Service table. Once it has found the proper Service 
table, it can follow the links to the tables of class Resources 1409 and locate the 
Resources table corresponding to the resource in the request. Froni there, there is a link 
to a table of class Resource Group Elements 1407 which relates resources to the resource 
group identifiers for the information sets they belong to. The resource group identifiers 

20 in turn specify tables of class Resources Group 1403, and these tables have links to tables 
of class Resource group Tree^ from which the hierarchies of resource groups can be 
determined to which the resource specified in the request belongs. Having done that, 
access filter 203 has found the resource groups that are relevant for determining whether 
the request should be granted. Resources table for the resource further contains the 

25 sensitivity level for the resource. Again, the information in information set tables 1401 is 
compiled into MMFs. When the request reaches the first access filter 203 in the path 
between the user and the server that provides the resource, the first access filter 203 uses 
the MMF files to make a determination that is the logical equivalent of the one just 
described. Thus, after examining the MMF files that contain the information from User 

30 Groups tables 1301 and Information Sets Tables 1401, the proxy has determined the trust 
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level of *e iae„.ifica«on. the .ensHivity level of U,e infonna,io„ *e user 

^„ps user belongs and *e ■.nfom.a.ion seU .he lnforn,a«o„ resource belongs .o. 

S '"r.!*^ *°'.^Mes used in aocess control database 30, to defme access control 
% included in these policies are access policies, adn-inistrativ. policies, and pohcy 

maker policies: 

Access policies relate user groups to resource groups; 
. Administrative policies relates a user group whose members are admin.strators to 

10 one of: 

1. another user group 

2. an information set 

3. a resource 

4. a location (site) in the VPN 

5. an access filter 203 or other server 

6. a service 

. Policy mate policies relate user groups of administrators to informatton sets. 

..ch policy relates a which is always a ^-e of ch. Oro^sJ^ 

,„ a side. Which, depending on the , 

R..nurces 1409 a table of class Resource Groups 1403 (representmg in 
Resources I4uy,aw .^..^na table of class Servers 1 4 1 7, or a 

ui ^ites 1415, a table of class Services 1413, a taoie oi ci<»» 

: .3.. ..icy tables 1.01 thus .1 

len-hand tables 1603. policy tables .605. and right-hand tables 160^ 
K oolicies is hierarchical: a member of a user group whose User Group table 
" ;tls r a group Of a type of A....-r..rs can change access policies as 
T^L by the administrative poUcy for the group. In turn, those adrntmstrators may 
specify other administrative policies rela«:d to their sub-domam. 
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Corresponding to the three kinds of policies, there are three classes of tables in policy 

tables 1605: tables belonging to Policies Access class 1611, Policies Administer class 
1613, and Policies Policy Maker class 1619. Tables of all of these classes share a 
number of features: they contain the ID of the user group table for the left-hand side of 

5 the policy, the ID for the table representing the item specified in the right-hand side of the 
policy,/an indication of the. policy (access allowed or denied)^ an indication of whether 
the policy is pre-defmed and cannot be deleted, and an indication of whether the policy is 
presently active. The difference between the classes is what can be on the right-hand side 
of the policy, and therefore the links to the entities on the right-hand side; in the case of 

10 access policies and policy maker policies the right-hand entities are information sets 
only, and consequently, tables of the Policies Access and Policies Policy Maker classes 
contain right-hand links only to tables of the Resource Groups class, while tables of the 
Policies Administer class may contain right-hand links to in the alternative tables of class 
User Groups, tables of class Resource Groups^ tables of class Sites^ tables of class 

1 5 Servers y tables of class Services^ and tables of class Resources. 

The rights given the user group specified by the user group on the left-hand side of an 
administrative policy over the sets of entities specified by the right-hand side vary 
depending on the kind of entity, as shown in the following table: 


Left- 
hand 
Side 

* 

Right- 
hand 
Side 

Meaning of ^^allowed" Access 

User 
group 

any 

Members of the user group can create administrative policies 
for the target or included items. This allows for the 
delegation of responsibilities. 

User 
group 

User group 

Members of the user group can administer the target user 
group, including nested user groups. Allowed administration 
includes deleting, moving, and copying the target user 
group; nesting it in another user group; adding members to 
it; and nesting other user groups in it. 

User 
group 

Informatio 
n 

Members of the user group can administer the information 
set, including nested information sets. Allowed 
administration includes deleting, moving^ and copying the 
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set 


User 
group 


Site 


User 
group 


Access 
Filter 


User 
group 


Server 


User 
group 


Service 


User 
group 


Resource 


target information set; nesting it in another information set; 
adding members to it; and nesting other information sets m 


it. 

Members of the user group can administer the site including 
elements under it from the Available Resources lis (all 
Access Filters, servers, services, and resources). A»owed 
administration includes deleting and moving the site; adding 
it to an information set; and adding locations and Access 
Filters to it. Control over the Intranet location is necessary in 
order to define new Access Filters. 
Members of the user group can administer the Access Filter, 
including elements under it from the Available Resources 
list (all servers, services and resources). Allowed 
administration includes deleting and moving the access 
filter; adding it to an information set; and adding servers or 
services to it. 


Members of the user group can administer the server, 
including elements under it from the Available Resources 
list (all services and resources). Allowed administration 
includes deleting and moving the server; adding it to an 
information set; and adding servers or services to it. 

Members of the user group can administer the service, 
including resources under it from the Available Resources 
list (all resources). Allov^ed administration includes deleting, 
moving, and copying the server; adding it to an information 
set; add ing resources to it. 

Members ofthe user group can administer the resource. 
Allowed administration includes deleting, moving and 
copying the resource and adding it to an information set. 


The following table describes the rights given administrative user groups when they 
appear on the left-hand side ofa policy maker policy: 


Left- 
hand 


Rifxht-hand Meaning of "allowed" Access 
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hand 

Side 

Side 


User 
group 

Information 
set 

Members of the user group can manage access policies 
controlling access by any user group to the information set, 
including nested information sets. They may also include 
the information set and any of its descendants in a further 
policy maker policy. 


As pointed out in the discussion of the Information Set tables above, the proxy that is 
doing the access checking can use the User Group tables and the Information Sets tables 
to fmd the user groups the user making the access request belongs to and the information 

5 sets the information resource being accessed belongs to and can also use these tables to 
determine the trust level of the user identification and the sensitivity level of the 
information resource. The' proxy can thereupon use the Policies Access tables to find 
whether any of the user groups the user belongs to may access any of the information sets 
the information resource belongs to. If any such user group is found, the user may access 

0 the information set if the request's trust level is as high as the information resource's 
sensitivity level. To determine the request's trust level, the proxy must determine the 
trust level of any encryption technique being used and/or the trust level of the path in 
* VPN 201 that is being used for the access. This information is available in access filters 
tables 1701, shown in FIG. 17 and described below. If either the access policies or the 

t- 

5 access request's' sensitivity level do not permit the access, the message is disregarded and 
any session it belongs to is dropped. The access checking process is substantially the 
same when the request is a request by a user who is a member of an administrative user 
group to access database 301, except that when access is permitted, it may result in a 
modification of the database in accordance with the rules set forth above. That 

0 modification will then be propagated to all other access filters 203 in VPN 201 . 

Server Tables: FIG. 17 

FIG. 17 shows the schema for tables that are particularly significant for the operation of 
servers in the VPN. There are three kinds of servers in the VPN: 
5 • Plain servers. These are the servers upon which the resources are stored and 
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10 


15 


20 


which execute the services by means of which the resources are accessed. 

• Access filters 203. -.^ 
. PoUcy n-ana^ severs. These ^ access filters 203 ^ addi.o»Uy — 
L L*„« aa^base 30, and/or gen^ ^o«s about o^on and ^ of 

the VPN. 

An access filter 203 may function additionally as a plain server. 

^,^t. ;n thp VPN Information in the 
There is a table of class Servers 1417 for every server in the VPN. 
There .s a tab ^.^^^^^ ^^^^ ^p^„t,„g 

ioKIp for each server included its lU, name, uumam 

table tor eacn additionally a policy 

svstem its Internet name, whether it is an access filter 203 ana a ' 
sysiem, ita ^ ^ whether it is 

server whether access to it is available only via an access filter 203, 
server, wne additionally has an identity that 

„e:H^ thP VPN If the server is an access tuter zu;), u auu ^ ^ 
mside the VPN. •„ vPN 201 for purposes of authentication and 

access filter 203 provides to other entities m VPN 201 for purpo 
encryption In a preferred embodiment, the identity is the X.509 certificate for the acc s 
encrypuon. ih^k , - t a^c ^ mihHc kev for access filter 

fiUer used by SKIP. The X.509 certificate also .ncludes a pubho key fo 
1 The public i=ey may beloug to one of a number of name spaces; the NSID (name 

s an ideLer tor the public key-s name space; the MKID (master key ID) 
C e tTeTu tkey within the name space. Also included in d,e table is a Unk to a 

cLficl « 1 that indicates d.e certificate authority that rssued 

«^ certificates, and in that cas. their Se^er tables .1.1 have the s^er s 


NSlD and MKID. 


25 


• the VPN has one or more services running on it. For example, an 
Every plain server m the VPN has or ^^^^ 

access to files (the resources) on the server smai & 
FTP service provides access ^^^^ p^^.^ 

•™";^':ir r:i^^^^ - resources available on 

rrrlr rshlnT "... .hese tab.es include tables of class U.. wh^ 

the services, tables of class ..o... .409. which represent the resources 
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available via the services, and tables of class Service Definitions 1715 which define the 
service. 

The remainder of the tables for which FIG. 17 gives the schemas contain information that 
5 is used by access filters 203. The tables whose classes are shown at 1705 contain 
information used by access filters 203 that are policy managers to distribute database 301 
and/or to generate reports; the tables whose classes are shovm at 1717 contain 
information about optional parameters for the software being run by a given access filter 
203; those whose classes are shown at 1709 contain information about the proxies and 
10 other software modules that access filters 203 use to do protocol-level access checking in 
access filter 203; and the tables at 1707 contain information about trust and sensitivity 
definitions for identifications of users and kinds of encryption. 

The tables indicated.by the reference number 1708 contain information about the VPN to 
15 which access filter 203 belongs. Access filter 203 uses this information to route sessions 
and also to determine the trust level of the path being used for a given session. Routing 
table class 1721 defines tables that list the cun*ent routes to all networks accessible from 
access filter 203. It is automatically updated as those routes change. Attached Network 
class 1723 defines tables that indicate for each access filter 203 the networks that access 
20 filter 203 is presently attached to; tables of that class contain links to tables of class 
Network Definition, which in turn contain a link to a definition in trust definitions 1707 
which indicates the trust level of the network. The last class in this group is Point to 
Point Connection 1713, which defines tables that describe connections between access 
filters 203 accessible via the VPN. There is a table for each combination of source and 
25 destination access filter 203 and a link to a trust definition that specifies the trust level of 
the path between the source and destination access filters 203. The trust level in this 
table is based on the encryption technique used for messages traversing the path. 

As previously explained, the User Group tables 1301 and the Information Sets tables 
30 1401 provide the information needed by access filter 203 to determine whether the access 
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^r.A jlUn nrovide information about the 
i_i i/:ni rt^rmit the access and also proviu^ 
policies of Ub,« 160> pe-m,. *c ^^^^ ^^.^^^^^ 

;tW/;tv level of the resource bemg accesseo. /^^^^o 
sensnivty level t ^^^^.^^ ^.^.^^^ ^^^^ 5^,,, 

provide the informauon needed by access filter ^ j^^^j^ available 

^ u ,th in the VPN being taken by the session and the trust leveis 

I^irxhus if access Alter 203 determines .ha. . given - wishing u. 
5 enco,>t.on algonUtms. Thu^, .f a ^ 

r U^^" Jan. .e an^en^caUon ieve, use. 

informafon se. u> «*.ch *e gtve ^^^.^^ 
to, the user's ,den.if,ca.ion ,s no lower *an ma. re,u, 

- TlaTf nTrr Lrrr Ueve, . necessar. 


the session. 


Available Information Tables: FIG. 15 


15 


AvailableInforinanoni-u.«.. The tables are used by 

Pig. 15 shows the schema for available infonnat.on tables 501. The .bles ar y 
L 203 to produce available resources display 1005, shown . FIG. 10. TheJ, 

shown at 1502 relate each server to its services and to the resources provided by 
classes shown at 15U^ organizes the available resources into a 

• „ Thp. table classes shown at 1 504 organizes 
tf,e services. The table classes hierarchical list 

Mer^hy for inheritance purposes and re^s^ - ^ ^^^^ 
at 1 005 and by following the links from the bite meme 
) shown at 1005. and Dy 5 . i._rchy of sites, servers, services, and 

r.it«.r 203 can determine the nierarcny ui o » 
tables, access filter 203 can distribution tree of access filters 

„. The table classes at 1503, ^^^^^^^ 301 is 

,03. AS will be explained in -^^'^^' '^^^^^^^ 
modified, the tree defined by those tables determines the 

15 distributed to the access filters. 

ModUylng .ccess C^^^^^^;;^^ ^ .^Heate of ^ cop, of 
AS previously mennoned. each access 

_ control database 30. 301 .s 

30 203(a) of FIG. 2. FIG. 19 shows how that copy 
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modified and how the modifications are distributed from access filter 203(a) to the other 
access filters 203. 

FIG. 19 shows access filter 203(a) with master policy manager 205 and another access 
5 filter 203(i) at which an administrator using a workstation is modifying access control 
database 301. The messages 1909 needed to distribute and synchronize the modifications 
are encrypted using SKIP and sent via VPN 201 using a protocol called the private 
communications service (PCS). Each, of the access filters has a number of copies of 
access control database 301. Any access filter 203 has at a minimum two copies: live 
10 database (LDB) 1907, which is the database currently being used to do access checking, 
and mirror database (MDB) 1905, which is a copy of the database that can be switched in 
to be used in place of live database 1907. Thus, access filter 203(a) has an MDB 1905(a) 
and an LDB 1907(a) and access filter 203(i) has MDB 1905(i) and LDB 1907(i). 

15 If an access filter 203 is being used by an administrator to modify access control database 
301, then it will additionally have at least one working database (WDB) 1903. The 
working database is a copy of the database that is not being used to control access and 
therefore can be modified by the administrator. The administrator does so using a 
workstation or PC connected via a network to the access filter. The workstation or PC 

20 displays the administrative graphical user interface described above, and the 
administrator uses the GUI to make the changes as enabled by administrative policies. 
The changes may affect any aspect of the information stored in access control database 
301. As indicated above, where the changes are changes in access or administrative 
policies, the administrator can use the policy evaluation feature to see the effect of the 

25 changes. When the administrator is satisfied with the changes, he or she clicks on the 
apply button and the changes are distributed to all of the access filters and incorporated 
into each access filter's live database. 

The process of updating all of the live databases is called database synchronization and 
30 distribution. The process has three phases: 
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r tu. access filter 203 where they were made 
. nrs. *e moamoations are «n. ftom <^^^'^ ™„er database 

(here, aecess filter 203(0) to access filter 203 to wh 
^,ongs (here, access filter 203^»^ ^„„^ 
• There, the changes are '^'^-^^ ,^3^,, ^„ ,«pp>„g Uve 

-.ncorporatlng the ^^J^^^^^^^^ ^ ^ .Hangta, the aew mirror 
database 1907(a) and mirror database j, 

::ne It are dls.Hbu.ed <W>™ Ote Master Poll. Manager to other Access 


10 


15 


F^*^^^^' . ' ♦u^ «.mp fashion as with access filter 

^ access fiher 203. s,nchro^l«l«n '^^^ ^ ^^^l^rs 203 of VPN 20, U 
,„3(a, reorder in which *e.*ansesa."^^»^ ,01. 
determined by distribution tree 1511. «h.oh.n. ^, „, u,e ttee. By 

^ ac«ss filter 203 «ith master ^^■'J-^'^l'^l^, p,,, _ger 205. 

default, the f«s. access fiher 203 ,n^M « VPJ^ _ ^ ^^^^^^ 

fiitprs 203 are installed, tney arc 
As other access tilters zuj <u 


Master Policy Manager. 


20 


^•.tributes changes to its children sequentially. As each 
The Master Policy Manager distributes chang _^ ^^.^^^^^ ^^.^ 

x-u on^ receives its distribution, it then oisiriout 
child access filter 203 receives iis ^.^^ complete 

..ans that a shallow distribution o.the top level. 

. distribuaon cycle tas«r than a deep "^^^ „„„ „ „a.ce 

An adminis.ra«>r with *e proper access can reconfl^« the 

ft A 


disuibution more efficient. 


. r A ,h, same Piece of information (for example, an 
, „ ™o administrators ^^'"-^ J ^ , synchronization conflict 

^ss filter definition) m drfferen. work ng da ^.^^ ^ 

can occur. When this happens, master pohcy manager 
incorporate into access control daUbase 301. 


3, Op.iml.io. Access Co.tr.. Database 3... FIGs. 21 and 23 
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Although appropriate for persistent storage and use by administration GUI 1915, database 
301 is not optimized for use in real-time access checking. As will be explained in more 
detail below, access filter 203 optimizes the data in database 301 that is required for run- 
time access checking and to make the display for the IntraMap. It does the optimization 
5 each time a new copy of database 301 is received in access filter 203. In its optimized 
form, database 301 is a set of Memory Mapped Files (MMFs) in which the access policy 
information is stored in a form which permits quick access. The MMFs are so called 
because they are generated as normal files, but then attached to a program's memory 
space and accessed by means of memory operations instead of file operations. A further 
10 optimization is achieved by using the MMF files to generate rules that are used to do low- 
level filtering of messages by IP source and destination addresses and port numbers for 
which access is allowed or denied. 

FIG. 21 shows an example MMF file 2303. the MMF file in question is 
15 DBCertificatesbyUserGroupFile 2101, which maps the certificate matching criteria used 
to identify certificates that belong to particular user groups to identifiers in database 301 
of records for the user groups specified by the certificate matching criteria. File 2101 
thus permits a proxy that has the certificate that identifies the source of a message that 
has been encrypted using SKIP to quickly determine the user groups that the user 
20 identified by the certificate belongs to. In the preferred embodiment, the certificate 
matching criteria are the O, OU, and CA fields of the X.509 certificate. 

Ail MMF files 2303 have the same general form: there are two main parts: a header 2103 
which contains the information being mapped from and a data part 2105 which contains 

25 the information being mapped to. Header 2103 contains a list of entries 2107. Each 
entry contains a value being mapped from (in this case certificate matching criteria 
(CMC) 2109) and a pointer 211 1 to a record in data 2105 which contains the information 
being mapped to (in this case, a list 21 15 of identifiers 2113 in database 301 for the user 
groups that the user identified by CMC 2109 belongs to). The entries in header 2103 are 

30 sorted by the information being mapped from (here, CMC 2109), so that standard fast 
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u .A to locate an entry 2107 corresponding to a given set of 
searching algorithms can be used to locate an entry z 

certificate matching criteria. 

I r.ef «f the MMF files 2301 that are employed in 
pir« 7^ A B and C provide a complete list of the MMi- luc^ 

FIGS. 23 A. B, and p The relationship between these files and the 

. one implementauon of access filter 203^ Th ^^^^^^^^ ^^^^^ 

tables of database 301 will be apparent from the descn^o 
nrovided in the table. Each MMF file 2303 is represented by an entry m th 
provided the subdivided into groups 23 1 1, 

indicates the file's name and its contents. \ nBUsersFile 2307 and 

2313 2319 2321, 2323, and 2422. Files of particular mterest ar. DBUsersF.le 2 0 

Pile 2309 which describe policies, DBCertificatesByUserGroupFUe 2101. 
0 DBResourcesFde 2309, which des P j^BR^s^^rcelDbyServicelDFile 2315, 

which is the MMF file shown in detail in FIG. 21, DBResource y 
wmcn is uic DBResourcesbyResourcelDFile 2317, 

. • L i„t=c I mi « of resources to resource IDb, uui^esuun-ca j- 
which relates URLs ot resource nRTrustTableFile 2325, which 

which relates resources to resource groups, and DBTrustTableFiie 

implements SEl^D table 601. Moreover, the 
15 following files are used to compile rules: 
DBServerlDByNameFile 
DBIPAndTypeByServerlDFile 
DBServicePortToProxyPortFile 
DBAttachedNetworksByServerlDFile 

20 DBRoutingTableFile 

DBRoutingTablebyServerlDFile 

• ovioT r,«aiiv are filtered to make list 2431, which is 
The files in IntraMap infomiation 2422, finally, are tiiter 
then downloaded to the client for use by IntraMap applet 241 1. 


25 


30 


no. 20 is a block diagram of architecture 200 

,„p,e.„»tati„n .own in HO. 20 aU Lp— n r.. 

xiir- ri^rHs 2013 are implemented m software, inesoiwoi 

NIC cards zui J arc I v ^,„.,fi,ctiired bv Microsoft Corporation, 

under the Windows NT brand operating system manufactured by M 
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The software components fall into two broad classes: those that run as applications 
programs at user level 2003 of the operating system and those that run at the kernel level 
2005 of the operating system. In general, the programs that run at the kernel level do IP- 
level access checking and encryption and authentication, while those that run at the user 

5 level do application- level access checking. Also included in the user-level components 
are software that manages access control database 301 and software that produces the 
MMFs and rules for IP-level access checking ft-om access control database 301. The 
following discussion will begin with the kernel components, continue with the user-level 
components related to access control database 301, and will then deal with the 

10 components for protocol-level access checking. 


Kernel-Level Components 

Network Interface Cards (NICs) 2013: These are the ethemet and token ring cards 
15 installed in access filter 203. Three network cards are typically configured. One is 
configured for the interface to the Internet, to a wide area network (WAN) 201 1, or to a 
network connected to another access filter 203. Another is configured for interface 2007 
to all client computers and a third is configured for interface 2009 to the servers 
providing TCP/IP services. If there, is no need for an access filter 203 to be interposed 
20 between clients and servers, there may be only two NICs 2013, one to WAN 201 1 and 
the other to a LAN. There will be no need for the access filter to be interposed if no 
servers exist at access filter 203's location or if it is acceptable for all local clients to have 
access to all local information resources. 

25 SHIM 2017: at installation time, a shim software module is inserted between two levels 
of the Windows NT brand operating system (the NDIS and TDIS levels). This causes all 
traffic for particular protocols to pass through SHIM 2017. In the implementation, all 
traffic for TCP/IP protocols pass through SHIM 2017, while non-TCP/IP protocol traffic 
goes directly from the NIC to the appropriate other kernel modules. SHIM 2017 invokes 

30 SKIP module 2021 as required to process the TCP/IP protocol traffic. 
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15 


SKIP module 2021: AU IP n«work «^,c U sen. through SKIP module 2021. It an 
Z2Z^- - SKIP .^e. -..e.. .oes no. re<^>re *e au«,e„.ica«on and 
rrrionned by SKIP, *en SKIP module 202. passes i. .o W f,..r module 2 .9 

iTJou. Jing pacRe. is no. .o be e„eryp«d, .hen SKIP module 202, sends 
Similarly, It an ouigoii B F u,:th «lKTP-tvDe oackets, authenticator 

directly to the proper NIC 2013 for transmission. With SKIP type pac . 
directly TO u h k .u.nticate a session and encryptor/decryptor 2022 

0094 in SKIP module 2021 serves to authenticate a session an ji- ... 

2024 in UKir m «e«ion level Both authentication and 

serves to encrypt and decrypt information at a session level. 

servcs> ^^i.^^ jk „,.^u«.r of other access filters 203, 

/^.nrvntion mav be done with an arbitrary number oi omer acw: 

irolms are se. b, IP module 20.9 for ou.go.n, pae.ce. based on SENO 
parameters or are speeified wirhin ineoming packets. 

SK.P module 202. main«.ns enough su,e informa.io„ for each o*er site ^s. i. U,ks » 
n: . can mainuln H.gh-speed ope,a..on for mos. SKIP-.ype packed. Pac^«s ^ 
SO in-ii It v.a /cViiirpH secret and temporary key 

somettmes 'parked' whi.e addi,iona. processmg (sh^ed ^c,e P 
ca.cu.a.ion) is performed, 'skipd' modu.e 2037 in user space 2003 performs fl. 


processing. 


20 


25 


TP Filter 2019- The IP filter operates on a set of rules that the rules compiler a 
IP Fitter 20iy. i nc ^„ ^ the access policies in access control 

component of database service 2029, makes firom the access pol 

database 301. The basic functions of IP filter 2019 are to: 

Pass traffic up to the TCP/IP stack. 

Fassiraiii f ff.. «necific IP addresses and according to 

Block traffic - explicitly drop traffic for specific IP aaar 

special rules for emergency conditions. 

Ip .raffc - impiiciUy drop .raffle .ha. ne,*er ma«hes any ru.es nor ,s allowed 

l:;::^' - r^her *an de.iver „aff,c .o .he indicated des.ina.ion, rou.e i. . a 
proxy application on the current machine. 


1. 
2. 
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5. Perform network address translation — change potentially illegal internal IP 
addresses to legal ones. 

6. Pass decisions off to prjpf (discussed below) upon establishing a new session for 
which access control cannot be decided strictly by the rules. Typically, this is for 

5 sessions that may be allowed by policies or by the VPN tunneling features 

described previously. 

IP filter 2019 performs these functions based on the following information: 

• Rules generated by the rule compiler; 

IQ. • Source and destination IP address and port; 

• Encryption, or lack of it, on the incoming packet; and 

• Desired encryption and authentication on outgoing packets. 

Components having to do with Database 301 

15 

Shared Directory 2028: VPN 201 uses a single access control database 301 that is kept 
resident in each and every access filter 203. All versions of database 301 in a given 
access filter 203 are maintained in shared directory 2028. Shared directory 2028 also 
contains each access filter 203's log files. 

20 

Private Connect Service (PCS) Module 2025: PCS module 2025 provides access 
filter- to-access filter communications in VPN 201. All such commiinications go 
through the PCS. The PCS has its . own IP port number and its messages must be 
encrypted. The particular functions carried out by means of PCS messages are: 
25 • Distribution tree management; 

• Distribution and synchronization of database 301; 

• Retrieval and distribution of routing table 1 72 1 ; 

• Retrieval of Windows domain and user information; 

• Network scanning; 

30 • Retrieval of log contents; and 
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20 


. Transfer of files used by reporting and other subsystems. 

ISDB Manager 2027: ISDB manager 207 manages database 301. It and the PCS are 
ISDB Manager ^^^^^^ ^.^3 

the only interfaces to the copies of database 3U i m ^ ^ ^ ^ _ . , 

the software used to read and write all tables in the copies of database 301. 

•1 -yMQ. DR Service 2029 produces MMF files 2301. It 
DB Service and Rules Compiler 2029. DB Service p 

h time a new copy of database 301 is received in access filter 203. It utilizes 
does so each time a new copy ui ua , . , a(\nn\ for a siven 

hv ISDB Manager 2027 to read live database 1907(1) for a given 
the functions provided by ISDB Manager 

r.t.r 103m and generate the MMFs 2301. A component of DB service 

11. ™= ™.e. spec., -''"":r:r: 

application program U.at sinply invokes rou«„cs m *e DLL. In nc.n, p 

■ ,1,. DLL are invoked by the DB Service whenever a mod.fied database 
routines m the DLL are invoKe j ,05 The application 

■ received in access filter 203© front master pohcy manager 205. T pp 
Iram is used in special modes during the installation and bootsttappmg process. 

M Files (MMFs)2301: As already explained. Ae MMFs 2301 are daU 
Mentory ""'^^^^H,, „u.i»d by a number of other monies 

files generated by DB Service moo feuowin. operations as efficient 

in access filter 203. The files are designed to make the following op 

as possible: 

Map from user identification to user group(s); 
Map from information resource to information set(s); 
. . Find policies that are associated with user groups; and 

Find policies that are associated with information sets. 

Components related to Authentication 
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Evaluator 2036: Evaluator 2036 is a set of DLLs that are used by each proxy in proxies 
203 1 . Evaluator 2036 provides the following functions to the proxies: 

• Prompting the user for further in-band or out-of-band identification information; 

• Obtaining out-of-band authentication information from the Authentication Tool 
5 Service (ATS);. 

• Obtaining the certificate associated with the current user from SKIPd; 

• Reading the MMFs 2301 and determining whether the access policies permit the 
user to access the resource; and 

• Implementing the trust/sensitivity calculations for the path if access is otherwise 
10 allowed, including deciding whether access may be allowed via the path and if so, 

what encryption and authentication is needed and which access filter is nearest 
the server. These functions are performed by a component of evaluator 2036 
termed the VPN manager. 

15 Authentication Tool Service / User Identification Client (ATS/UIC) 2039 and 2041: 

ATS 2039 is the server in a client-server application that gathers and authenticates user 
information. ATS 2039 runs on the computer upon which the other components of 
access filter 203 are running. The client part is UIC 2041, which runs on Windows- 
based clients. ATS 2039 and UIC 2041 are the mechanism by means of which access 

20 filter 203 obtains out-of-band authentication information. ATS 2039 aiid UIC 204 1 
communicate by means of a session which is separate from the session being 
authenticated. ATS 2039 gathers and caches the authentication information it obtains 
from the UIC clients and provides it to Evaluator 2046. The cached information from 
the clients includes 

25 • Windows ID; 

• Identity Certificates; and 

• Authentication token ID'S. 


30 


SKIPd 2037: 

Most of SKIPd's functions are in support of SKIP 2021. Those functions include: 
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H^cKange of cniflc.. i»forn.a.l<.» <^ co™n,u„«-.. This U 
done through the use of the Certificate Discove,y ProtocoUCDP). 

cliation of the Diff,e-HeU„«n sha^d secre. This shared seer« ,s t. * 
of SKIP. This eaicuiation ta^ a oonsiCetahie a.«.n. of t»e and 
is saved to disk in an encrypted form. , 
Cal,atio„ of the transport .ey useO to encyp. the session, T.ese Keys « for a 
t^f-r\nd of time or amount of data, 

rlln. SK,P. wih provide certi«cate ^chin. crtteria to the EvaiuatorCs, 
for use in user identification. 


Proxies 2031 ^ .„„^p^ ^fBo for a 

,3 P--* -'^t;:; : rL^^^ the .0.000. ^ it is .ntercepun, and can 
particular protocol. The proxy „ 

obtain the information re,u,red to .dent«^^< 

authenticate the user ftom dte nKSsages that are bemg J J 

• u * c\>iTP receive messages on ports other man uic 
All of the proxies but SMTP receive mes b .^^ 

,eir protocol, with the . '^^''i;^:^ "^ZIZ -^^^ it has 
^naard port to its --—^---^j;:: !.,, .He user has access to the 
oWained from the session to evaluator 2036 to decrde ^ 

„. If the user does have access, access titter iui 
, i„fom,ation resource ^f thj - ^ ^^^^^ ^ ^ 

Tp^^r:;:! . a ^efer^ — — ^ "^^^ 
embodiments may include proxies for other protocols. 

' • , The maiority of netv^ork uatfic occurs over a small number of proUicols for 
Pr_,pf: The majority ^^^^ a„ 

„Kich there are proxies in ^^'^II^^"^^-' - ^ ""^^ " 
a^ess decision must be made Ui -"^J^^^ ^ „ p^pt 

,.el by IP filter 201,; when^^o P^__^^_^^^__ ^ .^^^^^^ 

30 Which Obtains whatever mformaUon relative 
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resources it can from the traffic and passes the information to evaluator 2036 to 
determine whether access should be granted. Prjpf is not truly a proxy, since it only 
makes an access determination for IP filter 2019 and does not pass any traffic to 
standard protocol software. \ 

5 . 

FTP: The FTP proxy handles TCP/IP packets for the File Transfer Protocol. In a 
present embodiment of VPN 201, access control is only enforced to the account (logon) 
level; in other embodiments, access may be controlled to the file access level. During 
the FTP logon portion of the protocol, the proxy determines the server and account 
10 being accessed and provides this information to evaluator 2036 to determine whether the 
user belongs to a user group whose members may access the information sets 
corresponding to the account. The proxy further handles the in-band authentication 
using tokens in interactions with the user that are specified in the FTP protocol. 

r 

15 FTP is actually a very complex protocol, involving both an active and passive mode 
(used in Web browsers and some automated FTP clients). In addition, FTP data transfers 
utilize a second, dynamically determined TCP session. This requires a special interface 
between the FTP proxy and IP Filter 2019 so that the FTP proxy can indicate to IP filter 
201 9 that it should allow the second session. 

20 

HTTP; The HTTP proxy is built from the source code for die public domain CERN 
implementation of HTTP and contains all of its caching logic. The proxy uses evaluator 
2036 to check each access to a URL. No in-band authentications are performed with 
HTTP. 

25 " ' 

Telnet: The Telnet resource is only controlled to the server level due to the non- 
standardized nature of Telnet logins. The Telnet proxy is only used in order to provide 
additional in-band authentications. It is the simplest of the true proxies. 
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>n.TP (Network News Transfer Protocol) is used »co„uol bo* news f«d 

^ ''-^"^-'^^^^Z ^J^ Have been Uan^at- >n.o .SC., 
uuencoded message. These are aty ^^^^ 

text tor t-e purposes of f""^^ ,^Hes a., pa«s of binary 

5 messages to Keep ^ U> a reasonable s,ze. The W^TP P y ^ 

m^sages. For each such message, if " a„.i.vuus 2033 

. • ^ «,Ac<:aae then the entire multi-part message i» <^ 
multi-part message, men rjurine the news reading 

.Hecks it tor viruses as descHbea in .ore deta. Wow. D^g ^^^^^^ 

..... ---t^-^::rr:ara-;r 

protected at the server leve, only. T^ re^a^J ^_ 

— i^: r ;l ^ 

15 real audio proxy has an interlace lo ir 


2019 that the return UP channel is allowed. 
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TH SMTP (Simple Mail Transfer Protocol) differs from the other proxies in 
SMTP: The SMTP (Simple m ^^^^p p^^^y 

that the IP Filter's proxy rules are not used o ^^^^^^ ^^^^^^^ 
Whereas the other proxies Tisten' on a non-standard po^ t e MTP p^^^^ ^^^^^ 

^ A .nrt ^25^ and then makes its own connections to the stanoar 
standard port (25) and me , ^^ct explicitly allow this access, 

software. The access policies in database 301 must exph 

■r c th. URL for the IntraMap, report manager 209 
,..„M.p= When a ^drdlloaded applet attempts to ntake a 

downloads .he IntraMap J- a«>>e^^ ' „. 
conneaion back to a socket of the access fllte 

filter 20,9 of loca, access Alter 203(1, intercepU to 
p„vides it to the ,n.raMap proxy o„ local access fi^r 0 0^ PJ^ 

i«t Kv findine the answers in the local copy ^ 
..^^es from the "PP"^;^*^ * ^„ ^,„, fl,.ered to reflect Ute user's 

returning the answers to the applet, wiin a 
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access rights. The IntraMap proxy is not a true proxy in that the entire connection is 
V always completely serviced by the instance of the IntraMap proxy that intercepts the 
connection. 

5 Anti- Virus Module 2033 

Anti-virus module 2033 in a preferred embodiment is a set of DLLs provided by Trend 
Micro Devices, Inc., Cupertino, CA. In other embodiments, anti-virus modules from 
other sources may be used. Anti-Virus module 2033 checks ail data entering VPN 201 
for viruses. In order to provide the user with feedback on the progress of the transfer 

10 and to prevent the user's client program from timing out, the data is transferred to the 
client and is copied at the same time into a temporary file used for virus checking. The 
last portion of the data, however, is not sent to the client until after virus checking is 
complete. As soon as the last portion is in the temporary file, the temporary file is 
checked for viruses. If no viruses are detected, the remainder of the data is sent to the 

15 client. If a virus is found, then the transfer is aborted. In a present embodiment, the user 
is notified of a failed transmission. If an administrator has so specified, an alert may be 
sent to the administrator. 

Launch, Log, Alert and Reports 2027 
20 The components of this module perform the following functions: 

• Launch - controls the initial sequence of startup tasks that takes place on an 
access filter 203 when VPN 201 is established. 

• Logs - a DLL that provides a standardized logging interface. 

• Alerts - a standalone program that watches all of the NT logs, looking for alert 
25 conditions specified in database 301. The method by which an alert is delivered 

is specified using the GUI for defining alerts. 

• Reports - a subset of the logs are forwarded to a special report log, concentrated 
into a database and later forwarded to Report Manager 209. 

30 Administrative Graphical User Interface 1915 
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fit^r 905 or on any computer having a 32-bit Windows 
The GUI may run on access filter 203 or on any c P 

brand operating system that is attached to access filter 203. Whether the 
access f her 203 or on an attached system, it utilizes ISDB MANAGER 2 27 to read 
Z l write to a working copy 1903 of access control database 301. All necessa^ 
lodif tils to access control database 301 are made through GUI 1915. An .pp y 
r;:^^^^^^^^^ GUI is se. as a signal to PCS 2023, which responds to the s,g.al by 
siting the previously-described distribution and synchronization operation. 

.etaUedE.amp.eofOperatlonorAccessFUter203:FIGS^^ 

In the following, the end-to-end encryption example of FIG. 5 w.ll be expla 

In the tollowmg, ^.^ ^^^^ accessmg a 

detail In that example, a roamer 503 Whose fi^ IS C4U HF 

detail, mma f vpm 201 When roamer 503 was set up to 

ci^ IP enuiooed server 407 inside a site on VPN 20 1 . wncn 

N 20 i. se. up .o do so via a^s f„«r 403(3) .sin. a particular ^ ot 
jr He. it wi.. be L.ed « <he type of enc^<io„ i^ing used by roarer 
ZZT^^Zl of "sec.." and .a. *e user wishes . access a Web page on serve. 
Z m Isitivity levei of "secre.". Since wha, is being accessed is a Web page, 
Ci "n! JhTTP protoco, for i.s session wi* U.e HTTP service on server 
roamer 503 IS using men I v vPN 201 and server 407 are all 

407 Since roamer 503, *e access filters 203 m VW 201, an 

„I wi* SKIP drey are all provided with their own public and pnvate Iceys. At a 
.,u,pped w* SKIP^ y P ,„3P, „ 

minimum, roamer 503 also l«s the ^ 
„Hichitdnec.smes.g.for ser^..mtem. ^ ^^^^ 

.,„..e ana « - ^.^ot inVpK .0, have or can get each other. 
Discovery ^'"^^^^ ^ .e e,uipped with SKIP. 

pubUc keys and the publK= key^ fo 
Additionally, each access filters 203 m VPN ^ui Kn 
other access Biters 203 and servers in VPN 201. 

of the messages which are sen. and received as part of the HTTP session between 

All of the messages ,„ft,mica.ed by SKIP. FIG. 22 shows die 

rnamer 503 and server 407 are encrypwu oiiu . . u cvtp 

roamer ^^^^^^^ ^^de by SKIP 

form taken by such a SKIP message zzui. 
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software on the system which is the source of the SKIP message. SKIP message 2201 
/ shown here is from roamer-503. Its main components are: 

Outer IP header 2203: Outer IP header 2203 is used to deliver the SKIP message to 
5 access filter 403(3). Contained in outer IP header 2203 are a source IP address 2209 for 
roamer 503 and^a destination IP address 2206 for access filter 403(3). Destination 
address 2206 used by roamer 503 was set to specify access filter 403(3) when roamer 
503 was set up to access VPN 201. Source IP address 2209 may be dynamically 
assigned to roamer 503 by the Internet service provider that roamer 503 uses to connect 
10 to Internet 121. Outer IP header 2203 further contains ^ message type (MT) field 2208 
which specifies that the message is a SKIP message. 

• * 

SKIP header 2205: SKIP header 2205 contains the information needed to decrypt SKIP 
message 2201 when it is received.- SKIP header 2205 contains at least a destination 

15 NSID 2215 and destination MKID 2213 for the destination's certificate, that is, the 
certificate for access filter 403(3), and the source NSID 2219 and source K4KID 221 7 for 
the source's certificate, that is, the certificate for roamer 503. In addition, SKIP header 
2205 contains identifiers for the algorithm used to authenticate the message (MAC ALG 
2226) and the algorithm used to encrypt the message (CRYPT ALG 2225), as well as an 

20 encrypted transport key for decrypting the message (Kp 2223) and an identifier 2224 for 
the algorithm used to decrypt the transport key. 

Authentication header 2211: Authentication header 2211 contains a MAC (message 
authentication code) 2221, which is computed according to the MAC algorithm 
25 identified in field 2226 and which is used by access filter 403(3) to verify that the 
message arrived without tampering. 

Encrypted payload 2227: Encrypted payload 2227 contains the encrypted message 
which roamer 503 is sending to server 407, including IP header 233 1 for that message 
30 and encrypted message 2229. IP header 233 1 has the IP address for server 407 and the 
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po« number for *e HTTP pro^co, .rv.c. E„c,^»d P^^'">^^^";- ^^""^'^ 
by using Kp 2223 witt, the decryption algorithm specified by CRYPT ALG 2225. 

Handling SKIP Message 2201 

IKIP messase 2201 arrives on Internet inter&ce zui i oi « 

SKIP message ^017 sends 

Processing of tlte message begins at tl.e SHIM level m K 

ail incoming traflic to SKIP 2021. wKicK in turn recoil- 

message is a SKIP message. To decrypt and authenticate the message. SKIP n«ds to 
message is 4 SMKID 2217, DNSID 2215, and 

decrypt Kp , and to do that it provides SNSID 2219, iMKii^ i 
D^ID 22; 3 .0 SKIPd 2037, »hich uses the ID. to retrieve the certificates for roamer 
503 and access filter 403(3, fiom SKIPd 2037.S certificate cache. If a ^rtiflcate ,s no 
Zl SKIPd 2037 uses the CDP protocol to fetch the certificate. The information in the 
locates is then used together with access filter 403(3,'s private Key to create a 
s^ret value, which is then used to decrypt transport l.y Kp 2223 an .0 produ^ 
trttemal Key. Mp and B.p. SKIP secu^Iy saves the - "^^^ 

me^ages. since its computation taRes a significant "^^^ 
is computed for the enUre received message and the AIcp .s used with ^AC 222 ^d 
MAC IlO 2226 to verify that entire message 2201 has not been tampered with. If t^at 
*e case the ke, Ekp is used to decrypt encrypted payload 2227 .0 recover the 
* a. f l^ 503. Dcc^pted payload 227 is then provided to IP filter 

' Ih- n lies its rules .0 the source IP address, destination IP address, and port 

2Uiy, wmcii „^^oc TP filter 2019 follows another rule 

u TP header 2231. If no rule denies access, IP tilter zuiy luuu 

i I .rulcryptcd message together with SNSID 221, and SMKID 2217 to 
:! HTTP ply. IP fUer 20,9 uses the OBServicePortToPro^yPortPile of 


25 MMFs 


Processing continues at the application level in user level 2003 of .he operating system. 
tTcTt^P proxy has in hand the IP address of the server, Ute port number of the serv.», 
"web page, the certificate belonging «> the user of roamer 503, and the 
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encryption method used to encrypt* the message. It will use evaluator 2036 to determine 
the following from the MMF files 2301 ; 

• the user groups that the user represented by the certificate belongs to; 

• the information sets that the Web page belongs to; 

5 • whether there is an access policy that permits at least one of the user groups to 

V 

access at least one of the information sets; and 

• whether the trust level of the message is at least equal to the sensitivity level of 
the Web page. 

Beginning with the first of these tasks, evaluator 2036 receives the NSID and MKID for 

I 

10 the certificate and uses the certificate matching criteria from the certificate with the 
DBCertificatesByUserGroupFile to obtain the identifiers for the user groups the user 
sending the message belongs to. 

Evaluator 2036 determines the information sets by taking the IP address of the server, 
15 the port number of the service, and the URL for the Web page and using the IP address 
with the DBServerlDBylPFile to determine the server that contains the Web page, the 
port number with the DBServicelDByPortFile to determine the service on the server 
that provides it, and the URL with the DBResourcelDbyNameFile to get the identifier 
for the resource in database 301, and then uses the DBResourcesByResourcelDFile to 
20 get the identifiers for the information sets that the Web page belongs to. 

With the identifiers in database 301 for the user groups and information sets in hand, 
evaluator 2036 uses the DBResourcesFile to determine whether there is an access 
policy which permits any of the user groups that the user belongs to access any of the 

25 information sets that the Web page belongs to. In so doing, it may only consider user 
groups whose membership is determined using modes of identification whose trust 
levels are sufficient for the resource's sensitivity level. The DBResourcesFile maps 
each information set identifier to a list of the user groups for which there are access 
policies involving that resource set. For each user group, the DBResourcesFile further 

30 indicates whether the policy allows or denies access. Evaluator 2036 uses the 
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OBRcsourcesBUe » — e fo, each i„fonna.io„ .n ^ --e Web ,».e 
.elongs «> »he*er *e Us. of user ^up. for which .here ^ access pohces w * regard 
1 rinfcm„.ion se. includes one of .he user ^ups « which «.e ose, belongs. If 
It i an access po.ic, for an. of *e use. group. U.a. denies access .he .aU.a». 
i„aica.es .o d-e HTTP prox, .ha. access is deni^; if *ere is no access poi.cy for »y o 
Tuser groups « denies access and a. leas, one .ha. allows access, .he eval^^r 

fn i d oU,epr„x,*a. access is allowed; ^ ^''^ °' ^ ^:^^tr 
of d,e user groups. ..e evalua.. de«m,ines if U,ere is a. leas. ce«,«^«e^ 
Jen based user group «.a. has an aUow policy for *e resource. It ^ ^ ^ 
reducing cUen. has a UIC running, d.en .he UIC is con.ac«d .o asK .he u^ 
addUionai iden.i.y infonnaiion; if addi.ion^ iden.i.y informauon comes bac^he 
process described above is rcpeared. Ofterwise, *e eva.ua.or .nd,ca«s . *e HTTP 
proxy that access is denied. 

Of course evaluator 2036 will also deny access if the access request does not have a 
Of course, evaiu . web oaee Evaluator 2036 obtains the 

trust level equal to the sensitivity level of the Web page, cva , ^ ^ , 

:„!i X .ev.> of web page fton, .he DBResourcesByResourceU^File. *e «.s 
" Jfl user idenUf.ca.ion DBTn.s.AuU,en.ica.ionsFile, and d,e .rus. level of 
r :Uon nreU^ .*o. .he f,BTrus.Encr.p.io„sPile. Since SKSP - 
Isagrwi* a med,od ^ has *e "secre." uus. level, .he mis. level of *e pa.h 
message wiui „ :„ ,hk examole To determine whettKr die mis. 

through .he nework is no. of concern m d..s example. 

levels tor d,e user iden.ifica.ion and fte encryprion me.hod are sufficen for *e 
luiJ^ leve, of *e Web page. Ev.,ua«,r 2023 uses d,e OBTn.s.TableP. e. wh,ch 


25 


2036 indicates to the proxy that the access is allowed. 


r .A th«t access is to be allowed to the information resource 
once the proxy has confirmed that access is ^ b 

specified in the message, the proxy originates a new session 

HTTP service on server 407. Proxy 2031 sends a special message to IP filter 2019 
30 "mng it to allow the specific session through, since otherwise this session would 
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probably be blocked by rules or sent again to a proxy. The message to IP filter 2019 
also includes information about the encryption needed for the new session, which in this 
example is that the session should be encrypted to the final access filter 403(5) and 
shbuld use encryption suitable for the data sensitivity level, which is secret. When IP 
5 filter 2019 encounters the new session, it finds that it matches the criteria specified by 
proxy 2031. so it passes the session to SKIP. Since encryption is needed for this 
session, the message will be reencrypted. SKIP 2021 creates a SKIP message 2201 in 
the same fashion as described above, except that: 

• Outer IP header 2203 for the message specifies access filter 403(3) as the source 
'0 of the message and access fi Iter 403 (5) as the destination ; 

• SKIP header 2205 has SNSID 2219 and SMKID 2217 for access filter 403(3) 
and DNSID 22 1 5 and DMKID 22 1 3 for access filter 403(5), and the other values 
in header 2205 are also those required by the fact that the source and destination 
for the message are now access filter 403(3) and access filter 403(5); 

• Encrypted payload 227 is the same as before (except that it has been encrypted 
using a different key) and MAC 2221 is produced as required for entire new 
message 2201 . 

As the proxy is relaying the message it is also watching for file transfer types that 
might contain viruses. When it encounters one, it applies anti-virus software 2033 to 
these files. If a file contains a virus, the proxy fails to deliver the complete file, thereby 
rendering the virus harmless. If access control database 301 so indicates, the proxy 
sends an alert when anti-virus software 2033 detects a virus. 

As new SKIP message 2201 is received at access filter 403(5), it is passed to SKIP 2021, 
25 where it is authenticated and decrypted as described previously. By the same 
mechanism as described above with regard to access filter 403(3), IP filter 2019 on 
access filter 403(5) recognizes that the message is destined for the HTTP application 
protocol, so it directs it to HTTP proxy 2031. That proxy accepts the message, then 
sends information it can obtain about the message's originator (access filter 403(3) from 
30 outer IP header 2203 and SKIP header 2205 to evaluator 2036 to determine whether the 
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»sion behE instigated by .hi. mcsage should be allowed ,o proceed. Eva.ua.or 2036 
Z 12 IP addres. of U,e message as well as *e o.her iden.i.y informauon, 
ex»n,nes *e source IP add a« MMF file DBServerlDBylPF.le, 

„d by ,ool<i,.g 403(3). uses *a. iden.ir,er.o 

~ *; — ^^^^^^ ma.hes .he 

ITU Art'^n^ is thereby recognized as an access filter 4U3 
«f tka me<:<:aBe access filter 403(.3), is mercuy i^^e, 
source of the message, acc allowed, for the 

•.u- VPX! ?01 so evaluator 2036 responds that the session snouiu 
within VPN 201, so evaiu ^.^^.^ 


10 


within VPN 201, so evaiuaior ^w.u .^.p ^ 

reason that it is a message already permitted by another access filter 403 withm ^ 

VPN 201 This decision to allow the message is returned to the http proxy 2031. The 
VPN 201. This d ^^^^^^ ^^^^^^ ^j,^^ 

evaluator2036w.ll instruct http proxy 203 ion ^ .^.^st is processed, 

th^ Qame session, for the same reason. As tne nnp rcqu 
that comes over the same session, ^^^^^ ^^^^ ^^^^ 

the proxy will establish an outgoing cor^nection to the http serv 

same manner as the outgoing session was established on access filter 403(3). 
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When the connection is initiated to server 407, evaluator 2036 looks up the IP address of server 
407 in the MMF file DBServerlDBylPFile to determine the identifier in database 301 for 
server 407, uses the identifier to locate the table for the server, and uses the certificate 
identifier from that table and the DBCertificatesFile to find the certificate for server 407. Then 
5 it uses the keys for access filter 403(3) and the public key for server 407 (obtained from the 
certificate) to construct a SKIP session as described previously. The actual message is 
encrypted and authenticated, a SKIP header 2205 is added, and an outer IP header 2203 is 
added, directing the message to server 407. 

10 When the message reaches server 407, SKIP in server 407 checks the authentication on the 
message, decrypts it, and forwards the decrypted message to the HTTP service, v^hich 
performs the access to the Web page requested by the message contained in the payload. 
Having obtained the Web page, the HTTP service makes a return message with an IP header 
specifying roamer 503 as the destination. This return message is then encapsulated in a SKIP 

15 message 2201 as previously described. This SKIP message is directed to access filter 403(5) 
and contains the mformation in outer header 2203 and SKIP header 2205 that is required for a 
message between those entities. 

When the reply message reaches access filter 403(5), it is authenticated and decrypted by SKIP 
20 2021 there, and forwarded to IP filter 2019. The message is found to match an existing session 
so evaluation is not needed; it is forwarded directly to HTTP proxy 203 1 . There it is checked 
for validity as an HTTP protocol reply message and retransmitted back to the originator of the 
HTTP session, which is access filter 403(3). Checking by the anti-virus module 2033 is not 
done since the originator of this session is known to be another access filter 403 in the VPN 
25 201, as it is known that access filter will do the checking if needed. The retransmission of the 
reply is again processed through SKIP 2021 and encrypted as above, using the SKIP 
parameters required for an exchange between access filter 403(3) and access filter 403(5). 
When this reply message reaches access filter 403(3), precisely the same thing occurs, that is, 
the message passes through SKIP 2021 and IP Filter 2019, to the http proxy 2031. There it is 
30 checked for validity as an HTTP protocol reply message^ possibly passed through the anti-virus 
module 2033 (if the message content type warrants it), and retransmitted back to the originator 
of the HTTP session, which is roamer 503. The transmission of the reply is again processed 
through SKIP 2021 and encrypted as above, using SKIP parameters as set forth above for a 
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™ being «n. ftom access fiher 403(3) .0 reamer 503. The reply message is a-en 

message ocmg ac^i ^ . , cktP orovided to the user's 

received at roamer 503. where it is authenticated and decrypted by SKIP, providea 

browser, and displayed for the user. 

Generalization of the techniques employed in access filter 203 

The techniques employed in access filter 203 have been generalized m two ways: 

of ^licy evaluation .on. policy enforcement which permits entities oti.er than 

access filters to enforce policies; and 

• the policy database now not only permits definitions of users, groups of users, resources 

• P°"*^^ - •H.ntifiration new types of actions for which 
and groups, but also of new types of user identification, new type 

nolicies may be defined, and new types of resources. , ^ . ^ 

TheCwing discussion firs. descHi^ how pchcy eva.ua.ion may he sep^cd^m 

Sep.ra.io. of poHcy evaluation from poUcyenforcemen.: FlGs. 20. 26. and 27 

no 26 is a bloc. diagram of a policy entorcemen. sys.em 2601 in which P""- — " 
been separa.ed ftom policy enforcemen.. In sysum 2601. the no.,on of pohcy has been 
Ir^LI o include no. only access policy, adminis^ative policy, and policy mal^mg po cy, 
: : ^.ion Which a user may perform on an informaUon resource For — . a PO - 
ly L .ha. a pardcular user group may prin. document beio.g.ng » a parucular 

information set. 

Qv<item 2601 has five main components: 

System zoui na^ performed on die information 

. requesting entity 2603, which requests that the action oe p 

resource, and which may be any entity that can belong to a user group; 

r .nfnrcer 2609 which can control performance of the requested action; 
. policy enforcer 2609, wmcn f .^eessible to or device controlled by 

. resources 261 l(0..n). which may be any information accessible 


policy enforcer 2609; 

nolicv server 2617, which determines whether the action is permitted; and 

dibase 2.9, .... co.^ns .o^^s fiom Which policy server 2617 

. ~ "C::^^^^^ and .licy server 2609 can each be located 
~ r Z '^uirLnt is that there be message transmission media between 
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requesting entity 2603 and policy enforcer 2609 and. between policy enforcer 2609 and policy 
server 2617. The medium between requesting entity 2603 and policy enforcer 2609 permits 
requesting entity 2603 to. send a message 2605 requesting that an action be performed on a 
resource 2611(i) to policy enforcer 2609 and receive an action response message 2607 from 
enforcer 2609 indicating whether the action was taken and if so the resuh. The medium 
between policy enforcer 2609 and policy server 2617 permits policy enforcer 2609 to send a 
policy request 2613 to policy server 2617 requesting policy server 2617 to indicate whether the 
policies in policy database 2619 pemiit a given requesting entity to take a given action with 
respect to a given resource and policy server 2617 to respond to policy request 2613 with a 
policy response 2615 which indicates whether the policies do permit the action specified in the 
policy request. It shoidd further be noted that the action controlled by policy enforcer 2609 
need not even be performed by a component of the computer system. For instance, policies in 
the policy database might control access by , library patrons to books and the action specified in 
a policy might be having a library page fetch a book from the stacks. 

The forms of the policy request messages 2613 and the policy response messages 2615 are 
defined by a policy protocol. Examples of standard policy protocols that are presently being 
developed are COPS (Common Open Policy System), which is available at 
hnp!//www.i?.tf orp/intemet-drafts/dr3ft-iRtf-rap-cr >ps-06.txt as of June 21, 1999) and RADIUS 
(Remote Authentication Dial In User Service, Internet standard RFC2 138). 

i 

Policy server 2617 obtains the information necessary to make policy response 2615 and then 
provides the response to enforcer 2609. Policy server 2617 includes a policy server database 
2619 which contains policies including one or more policies for the action which requesting 
entity 2603 has requested policy enforcer 2609 to perform on a resource R 2611(i). Policy 
server 2617 queries policy server database 2619 to locate the relevant pohcies and then applies 
them to policy request 2613. Doing this may require policy server 2617 to obtain other 
policy-related information 2623 from any location accessible to policy server 2617. One 
example of this process is the technique described in the discussion of access filter 203 by 
means of which access filter 203 obtains additional identification information about a user. If 
the information which policy server 2617 obtains from policy server database 2619 and other 
sources indicates that the action is pennitted, policy server 2617 sends a policy response 2615 
that so indicates and policy enforcer 2609 performs the action as indicated at 2610 and returns 
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4e «sui, via action response 2607 .o requesting «.ti,y 2603; if policy response 2615 indicates 
ftat fte action is petnutied. policy enfor«r 2609 sends an action response 2607 indicating 
that the action is not pennitted. 

5 A„ imporum, advan^ge of separating policy enforcer 2609 ftom policy server 26.7 is ^ 
policy enfor^r 2609 may be implemented a< many different levels within a system. wh«e 
^,em is to be understood to include systems made up of devices connected by networks. 
Policy server 2617 may contain policies for any policy enforcer, and consequenUy, ti>e actions 
which may be governed by policies are no longer restricted U. actions taken a. one or two 

10 levels of a system. 

no 27 shows a system 2701 witi. components that are connected by means of networks 
including a public network 2702 and an internal network 103. At the highest level, system 
2701 has one or more policy decision points 2723. which determine whether a policy permits 
,5 an action, and one or more policy enforcement points 2721. in which the decisions of the 
policy decision points are enforced. A policy decision point will include a policy server 2617 
and a policy enforcement point will include a policy^bled device, that is, a dev.ce whtch 
can function as a policy enforcer 2609. Communication between policy decision pomts and 
policy enforcement points is by means of policy messages 2725. which include policy requests 
20 2613 and poUcy responses 2615. When an entity 2603 re<r.ests that an action be perfonned 
using a resour^ 2611. the action will be performed by a device controlled by a pohcy 
enforcement point 2721. poUcy enforcement point 2721 will exchange policy messages 2725 
with a policy decision point 2723 to detemune whether the action is permitted, and tf it ts. 
policy enforcement point 2721 will cause the action to be performed. 

25 

Included among the policy enabled devices in system 2701 aret 

. a policy^led router 2713. which enforces policy a. the level of routing tiraffic m a 

physical network; . 

. policy enabled attached device 2719. which enforces policy a. the level of a device 

, r * ^ T7ni An *»vamnle is a printer which is able to consult 
30 attached to the network of system 2701. An example is a p 

policy server 617 to determine whether to accept a print request from a certain entxty 2603. 
. policy enabled application program 2717, which enforces policy at the level of the 
application program. 
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Each of the policy enabled devices deals with policy in the same fashion as described for 
policy enforcer 2609: when the policy enabled device receives an action request 2703 for 
which it must determine whether it conforms to the access policies established in policy 
database 2619, it sends a policy message 2725 to policy server 2617 and when it receives a 
5 policy message in response, permits or denies the action as indicated by the policy message. 

Continuing in more detail about the levels at which the policy-enabled devices of FIG. 27 
work, policy-enabled router 2713 may maintain tables of permitted sources and destinations 
for the packets it routes; when router 2713 is initialized, these tables are set up from 

10 information provided by policy server 2617; from then on, when router 2713 receives a packet 
with a source or destination that is not in its tables, it sends a policy message 2725 to policy 
server 2617 indicating the source or destination, and policy server 2617 responds to the 
message by indicating whether the source or destination is to be included in the tables. Of 
course, router 2713's tables may also be kept updated by messages sent by policy server 2617 

15 to router 2713 when policy data base 2619 changes. As can be seen from the foregoing, router 
2713 does policy checking at the level of IP filter 2019 in implementation 2001 of access filter 
203. 

Policy-enabled attached device 2719 is a device such as a printer which is attached to the 
20 network. The device is able to respond to a request by an entity to use it with a policy message 
to policy server 2617 and to proceed according to the information it receives from policy 
server 2617. Such policy-enabled devices 2719 permit a much finer granularity of control over 
such devices than is possible with access checking at the level of access filter 203. 

25 Policy-enabled application 271 7, finally, permits policy enforcement at a higher level than was 
possible with access filter 203. As long as policy data base 2619 contains policy information 
relevant to the resources being accessed by an application program, policy-enabled application 
2717 can exchange policy messages 2725 with policy server 2617 and can thereby determine 
whether to permit or deny the action which the user of policy-enabled application 2717 is 

30 requesting. One example of a policy-enabled application 2717 is one which implements an 
Internet service such as FTP, HTTP, or SMTP. This is the level which is handled by proxies 
2031 in FIG. 20. Because the services may now be policy-enabled, proxies are no longer 
necessary; instead, the higher-level Internet protocol can simply be passed on to the system on 
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which the service resides that will provide the access requested by the protocol. As shown in 
FIG. 27, the service can then itself exchange policy messages 2725 with policy server 2617 to 
determine whether the requested access should be permitted. 

Another example of a policy-enable application 2717 is a document processing program. In 
this case policy database 2619 may contain policies specifying sets of users that have the nght 
to modify sets of documents. When the user employs the program to select a document for 
editing the document processing program can exchange policy messages 2725 with policy 
server ^617, and if the policy response from policy server 2617 indicates that the user may not 
modify the document, the document processing program may so indicate to the user and refuse 
to permit the user to modify the document. 

J 

As may be seen from the foregoing, the separation of policy evaluation from policy 
enforcement and the extensibility of policy definitions together permit virtually any operation 
that a program can perform on a resource to be the subject of a policy, and thus makes access 
control systems like those sl^o^ in FIG. 2701 not only scalable and easy to manage, but easily 
adaptable to any present or future devices or programs. 

It should be pointed out here that policy evaluation and policy enforcement were logically 
separate in access filter 203, even though both wei. contained in the same device. When 
FIG 20 is looked at in temis of FIG. 26, it is apparent that GUI 1915, launch, log, alert reports 
2027 databases shared directory 2028, ISDB manager 2027, PCS 2025, and MMFs 2301 
implement a policy server 2617, while the remaining components implement a policy enforcer 
2609 that operates at the IP filter and Internet protocol levels. 

Generalization of policy: FIG. 28 

I„ access flUer 203. a. admims««>r with U« proper access could define new users and user 
groups could define new resources and infom>ation sets, and could add services and servers. 
An administrator could not define actions other fl>an access «> information. Further, the ways 
, in which one could define new user groups were fixed and resources were limited io sources of 
information. In the generalized policy server of the prefened embodiment d.ese limitations 
have been removed. It is now possible for administrators define new actions, new ways of 
defining user groups, and resources that are not information sets. Of course, the right to make 
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such definitions is itself determined by policies in policy database 2619, as explained with 
regard to administrative policies and policy maker policies in access filter 203. In most 
systems, definitions of types of entities, types of resources, and types of actions would be 
restricted to those people who belonged to the user group Security Officer. 

These new possibilities are illustrated in generalized policy syntax 2801 for policy statements 
shown in FIG. 28. Generalized policy syntax 2801 describes how policies will appear to 
administrators in the windows from which the policies may be manipulated. In FIG. 28, the 
items in italics are the components of the policy statements that may be defined by an 
administrator of policy server 2617 who has the necessary access to policy database 2619. 
The items in square braces are the words which relate the items in italics to define a policy. 
For example, 

Employees are allowed to Access the HR Web Site 

where Employees is a user group. Access is an action, and HR Web Site is an information set 
and the policy statement permits any user who belongs to the user group Employees to access 
any resource that belongs to the information set HR Web Site. 

Continuing in more detail with generalized policy syntax 2801, Entity represents a user group 
whose members are defined by one of the techniques employed in access filter 203 or by a 
technique defined by an administrator of policy server 2617; The only requirement for the 
entity is that it be recognizable by policy enforcer 2609* Action represents an action which 
may simply be access as in access filter 203 or an action defined by an administrator of policy 
server 2617; the only requirement for the action is that policy enforcer 2609 be able to cause 
the action to be performed on a resource. Resource represents an information set. In the 
generalized policy server, however, an information set may be a set of devices such as a 
printers or file servers. The only requirement for a resource is that policy enforcer 2609 be able 
to cause the action to be performed on the resource. 

Time Intervals 2809 permits the administrator to defme a temporal restriction on the policy that 
is being specified using generalized policy syntax 2801. When policies are being evaluated to 
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detennine whether a given user has access to a given resource, a policy that has a time interval 
is considered only if the time of evaluation is within the time internal. For example: 

Employees are allowed to Access the HR Web Site 
i from 9:00 am - 5:00 pm weekdays 

u , o«,«invpe<? to the HR Web Site to normal business hours. In a 
which liimts access by employees to me mv wcu ^ 

preferred embodiment, a Timelnterval may be defined as follows: 

• ranges of starting to ending times of day, 

• ranges of starting and ending dates, 

„ . „s.rictionoa days of*. ««ek and hoUdays:opions«, include or exdudesp^ific days of 

week and/or dates that are listed as holidays, 
. «smcaon on weeks of montt. allowing specification of every week, every X weeks (where 
X is a number ftom 2 u. 12) wift a starting refe^nce daK. or a Us. of week numbers w,tiun 
each applicable month, 
15 • list of ^plicable months of the year 

Ac,ionA..Wu,e(s) 281 1 are adnumstiator-defined definitions of *e manner in whieh d» acti^ 
permitted by .he poUcy s— ma, be carried ou.. Again, tire o^y re,u.remen. .s ^ 
poUcy enforcer 2609 be able .o carry cm *e action as specified by tire acuon anrrbme. For 

20 example: 

Marketing 1= allowed to print to the Marketing Printer 

with type=color 

This policy conrains ti« action a«ibu,. type-colcr, and tire policy permits users belong-ng 
« .0 tire user g«>up M^UHn, K> do color printing using tire resource MorfeHng Pnr,.er. 

Additional examples of action attributes are: 

. class of service required for the network connection; 

• route or media type to be used; 
30 • billing rate to be applied; 

• maximum quantity for this transaction; 

. maximum time allowed to complete the transaction. 
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As indicated by the syntax [with I when], time intervals can be used with action 
attributes as well as with entire policy statements. For instance, a policy that places a time 
limitation on a class of service looks like this: 

5 Everyone is allowed to access the World Wide Web with 

bandwidth=90% when weekends 

This pemiits entities in the user group everyone to access the Web with bandwidth=90% 
weekends. When a time interval has been applied to an action attribute, the action specified in 
10 the policy is performed as specified in the action attribute only if the request to perform the 
action is made within the time interval that is applied to the action attribute. 

Implementation of generalized policies: FIGs. 29and30 

FIG. 29 shows policy database 2901. Policy database 2901 is a modification of policy 
15 database 301 to accommodate the generalized policies defined by syntax 2801 and to work in 
an environment where policy evaluation and policy enforcement have been separated. Thus, 
in FIG. 29, policy query 2939 comes from policy server 2617 instead of access filter 203 and 
includes a specifier of the action to be performed as well as a specification of the information 
source or other resource upon which the action is to be performed. The results 2941 of the 
20 query are returned to policy server 2617. In addition to an indication of whether the policies 
permit the action, the results now include the values of attributes relevant to the action. The 
elements of FIG. 3 whose functions remain unchanged in FIG. 29 have the reference numbers 
that they had in FIG. 3. Beginning with access policy 307, the first additional item of 
information is access types definitions 2929, which define additional classes of actions for 
25 which policies may be defined in access policy 307. Next, there is attribute information 2927, 
which defines attributes that may be attached to entities involved in carrying out a policy. 
Included within attribute information 2937 are the following kinds of information: 

• attribute assignments 2937, which specifies what user groups, information sets, sites, or 
services an attribute is to be employed with. 

30 • attribute labels 2941, which define the names the attributes are known by in the user 
interface; and 

• attribute features 2939, which actually define how the attribute affects the user groups, etc. 
that it is assigned to. 
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. ,■ M25 defines time intervals that may be attached to pohc.es or to 
Schedules intormatroa 2925 defines U 

anributes. Within schedules utformaUon 2925. ^^'^^ ^ ,,35 

rjr: r tine, and use. . t„. 293, 

K database 2901 is implemented using Microsoft Corporation's 

to a preferred embodiment, datable 290 P 

„ell-la.o«n Microsoft® Access database so^. ^^^^^^^ 
ir^orm^ion ta the database is stored m tables. A u^^ .n ^ 
i^,es of the tables and their relatio^hips to ^oh ot^^ nOs^ ^ 
present application at. ^'-^^^^^^ »™ tables have refe^nce 

have the .efere^ ^ in HO. 30 show ho« the tables used .0 define 

numbers begtnnm. wtth ^ .he, 

ritrpi: --^^^ - - — "™ 

elements may be defined for polices. 

DetaUed implementation of time intervals ^^^^ ^ 

, Be,m.ns «ith the fime — ^^^^Te names that may appear in 
include a schedule defimUon table 3023 wluch de ^^^^ 
W«.rv*; 2809 in generalized poUcy syntax 280, and a sc^ 

aefincsschedulingrulesthatcanbe associated with ^^.^ a 

Schacluleoefinition table 3023. More than one sch«.*^ n^^^ - y ^ 

c;.heduleDef ID relates each scheduling rule defined in la 
,5 given name. ScheduleDe fields Day Mask through End Date define 

::::rr;rLr:.r;rn.vesadesc.p.nof.r.e.d.^ 

. mentioned above, time — ^ 

3„ .Ucies. Th.. -7'^ . identifier Sche.uX.Oe.O for a 

. 30 of a^ i^lai that is to be applied to the policy. Thus, when policy 
definition m table 3023 of a nmemte ..^i. „ an action request, it can locate the 

server 2617 is determining vvhether a pohcy .s appl.cable 
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time interval applying to a policy via the ScheduleDef ID field for the time interval in the 
entry in table 161 1 for the policy. Similarly, fittributeAssignment table 3007, which 
relates attributes to user groups, resource sets, sites, or services, includes a ScheduleDef ID 
field for any time interval applicable to that particular assignment of the attribute. The 
mechanism for defining time intervals, finally, is also used in a preferred embodiment for 
scheduling alerts, and thus entries in table 3023 are also locatable fi-om AlertSchedules 
table 302 L 

Detailed implementation of attributes 

The tables used to define attributes and relate them to the user groups, resource groups, sites, 
and services that they may be applied to are shown in attribute tables 3003 in FIG. 30. A given 
attribute is defined by entries in the tables AttributeLabels 3005, Attributes 3011, 
and Att ributeFeatures 3009. AttributeLabels table 3005 defines the labels used 
for the attributes in ActionAttribute(s) in policy definition syntax 2801. There is an entry for 
each such label, the entry including the label itself, a description of the attribute, the 
precedence of the label, and the type of the attribute. The precedence of the label defines 
y\ hich attributes will apply when more than one is connected with the policy evaluation. When 
one assignment has a higher precedence than the other, the one with the lower precedence is 
ignored. Each attribute label entry is identified by an AttributeLabell D . 

Each entry in the table Attributes 3011 gives a current definition of an attribute. The 
definition may have one or more AttributeLabellD fields identifying entries in AttributeLabels 
table 3005. The label defined by that entry in AtrributeLabels represents the attribute 
defined by the entry in Attributes 301 1. The current meaning of the attribute is defined 
by the fields in table 3011. Included are a description of the attribute, its type, the ID of the 
server it applies to, and the device type on the server. The fields AttributeFeaturelD 
and Valuel and Value2 are of particular interest. There must be at least one 
AttributeFeaturelD field. The field identifies an entry in 

AttributeFeatures table 3009 which defines kinds and ranges of values used in the 
attribute. Valuel and Value2 define either a current single value (Valuel) or a current 
range of values (both Valuel and Value2) selected from the kinds and ranges of values 
defined for the attribute in AttributeFeatures table 3009. 
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AS will be apparent from the foregomg, AttributeFeaturas table 3009 can be used to 
define new kinds of attributes. Each entry in table 3009 includes the identxfier 
AttributeFeaturelD used to locate the entry and fields as follows: 

. Class, the name of the class to which the attribute belongs (for example, quality of 
service, billing rates, or maximum quantity for a transaction); 

. Feature I D, a number that uniquely defines the feature within its class; 

• N ame, the name by which users know the feature; 

• De s cr ipt ion, a description of the feature 

. value Type, a definition ofthetype(s)ofvalues that define the attribute (for example, 
whether a single value or a pair is necessary, and data type information; 

. Feature Precedence, an indication of the order in which feattires will be applied in 
evaluating an attribute; 

. value Precedence,anindicationofwhetherthehighestorlowestvalueofarangeis 

to be selected; and 
• Restrictions, an indication of restrictions on the values. 

To define a new class of attributes, an administrator who is permitted by the policies of policy 
server 2617 to do so simply defines features for the new class in AttributeFeatures 
table 3009 and then begins defining attributes that use those features. A feature may be 
anything that is meaningfiil for the policy enforcer 2609 which will be enforcing the pohcy. It 
should be noted here that the general techniques described above for defining new k.nds of 
attributes may be employed elsewhere in policy database 2901 to define new actions, new 
ways of identifying users, and new types of resources. 

Once an a«ribute has been defmed by information in tables 3005, 301 1 , and 3009. it is related 
«> an entity to which the attribute may apply. This entity is termed the aaribute's subjec. 
A.signmen1:ID table 3007 specifles these relationships. Each entry in table 3007 relates the 
attribute specified in its RttributeLabel ID to a single subject; additionally, it may relate 
the attribute to a user group whose members may perfomt an acUon involving the subject. If 
the entry does not specify a user group, the a«ribu.e applies to any use of the subject; otherwtse 
, it applies only when the specified user group uses the subject. The subjects may be user 
groups, sets of resources, sites, or services as specified by the values of the fields 
UserGroupID, ResourcGroupID, SitelD, andSarverlD. Further fields m 
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table 3007 indicate whether the attributes sure active (i.e., to be currently applied), when 
application should start, when it expires, and if the attribute involves a time interval, a 
ScheduleDef ID value for the time interval. The Precedence field indicates the 
precedence that the attribute will have among the attributes assigned to a given entity. 

5 

In deciding which attributes to apply in making a policy decision, policy server 2617 proceeds 
as follows: When policy evaluation is complete, the. attribute assignments in table 3007 are 
searched for links to any of the user groups, resource groups, , sites, or services connected with 
the policy evaluation. If the entity performing the action belongs to a user group for which the 
10 attribute applies, the links from the attribute assignments 3007 are followed to the attribute 
labels in table 3005 and in turn to the attributes in table 3011 and finally to the attribute 
features in table 3009. Each of these linked tables (except for 3011) contains precedence 
information, which is used to determine which attributes in table 30 11 of those discovered by 
following all the links will actually apply to the evaluation. 

15 

These precedences are considered separately for attributes of each class as defined by the. 
attribute features in table 3009. Within each class, first the precedences in the attribute 
assignments in table 3007 are considered. Only those assignments with the highest precedence 
value are considered fiirther, though all assignments sharing the same precedence are 

20 considered. Next, the. label precedences in the attribute labels in table 3005 of the remaining 
linked attributes are considered. Only those labels with the highest precedence value are 
considered further, though all labels sharing the same label precedence are considered. Next, 
the feature precedences in the entries in At tribute Features table 3009 of the remaining 
linked attributes are considered. Only those attributes sharing the highest feature precedence 

25 are retained. Finally, for each attribute in table 3011 that is linked to the same entry in 

■r 

Attribu.teFeatures table 3009, the value precedence in AttributeFeatures table 
3009 is used to determine which attribute firom table 301 1 to use, by indicating whether the 
highest or lowest value is to be selected. 

30 At this point, at most one attribute defined in table 3011 for each of the relevant attribute 
feature entries in table 3009 vsdll remain, and the values and features in these entries wall be 
returned for use in evaluating the policy. In some cases, the request may indicate what 
attribute values are desired and the request may be refused if they do not match those specified 
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Op,in,u,,.g AtWbu.. Tables 3003 .od Time loterval Tables 3025 ^.^ ^3 

. • .h. discussion of aecess flltet 203 above and illusliated m Figs. 21 and 23, 

^, e reiT in "I enibodin^n. op«n.i.s policy da^base 2901 by gene^Bng 

C oT^o: :l ^ P-- en,bcdin.en. ^ ne» MM. Bles bave^..n add. . 

Tplin-i. *e info^a^on in .bles 3003 and 302S. Tbe .wo new MMF fl es - *^^°»- ' 
. OBPropertlesnie: Con^uns all amibuUs and schedules - *a. ean 

apply ,0 ote obiecu. Ms index is indexed by Prope«ylD in «.ose o*er objects. 

■ „ f.Datanie- All properties have a name. TOs file ts mdexed by 

A nRProDertiesMetaDatat lie. ^^^y 

Zny .ype (w>* one entry in «.e index for each property na.e cot^^ 
orrope« iesrile) and n^ps the nan^s «> a lis. of Propertym. to enable then, to be 
quickly looked up in DBPropertiesFile. 

user interface for titne •^^'^ J^'^J^'l _ ,„,rf,,, ^ in a preferred 

ltd:: rrrirror — have already been deftned. to de.e a 
:ra time interv. and to associate a ..e ..rv. ™- ^"d r3": l' ^ 

fi,re Shows a window 3102 used ^^^^J ^^^^^^'^ deLd rules by nan.e. 
all ofthe defined sctadules by name; subwmdow 3106 hstsaU of * 

The displayed infonnation comes from ScheduleDef .n.txon table 

ScheduleRules table 3025. 

u A u n«me reoresents the user selects the name in subwindow 3103, as 
, TO see what rules a schedule ^--^J-' ^3 3,,,aule has two 

t- -iin^ where Non-workmg Hours l^^^" -^^ 

SHOW, at .05^wh.e H ^^^^ ^ 

compon«,t selected, the rule(s) belon^ng to « 

and hohdays. shown « J^™ * ^ ^. schedule names for 

are highlighted mwmdow 3106. Conver^ly „ 3106 is the rule 

,0 the schedules that use .he rule are taghl.gh.ed. SI""™'"'"' 

for busmess hours, anoU»r of *e schedule names in subwmdow 3 103. 
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To make a new schedule, one clicks on New while subwindow 3103 is active and enters the 
new schediile name and then selects the new schedule name and highlights the rules belonging 
to it in subwindow 3102. To change the rules assigned to a schedule, one selects the schedule 
name and then selects different rules for the name in subwindow 3 106, To make a new rule for 
5 an existing schedule, one selects the schedule's name and clicks on New, at which point the 
new rule can be made as described below. One can also click on New while in subwindow 
. 3 1 06, create the new mle, and then relate the new rule to a schedule name as described above. 
A rule can also be related to a schedule name by dragging the rule to the schedule name and 
dropping it on the schedule name. 

10 

The window used to make a new rule is shown at 3201 in FIG.. 32. This is the window for 
modifying an existing rule or making a new rule. To modify an existing rule, one double 
clicks on it. Inputs in the window permit the user to define the interval of time which is being 
applied to the policy or attribute in terms of times of schedule validity (3203), days of the 
15 week for which the selected times are valid (3205), weeks for which it is valid (3207), and 
parts of the ye£ir for which it is valid (3209). As shown, window 3201 defines the schedule 
shown in FIG. 31 at 3111. That schedule is represented by Business Hours. The 
information shown in window 3201 is from ScheduleRules table 3025, and modifications 
made using window 3201 are applied to that table. 

20 

FIG. 33 shows the window used to add a time interval to the definition of a policy. Window 
3301 restricts access by users belonging to the user group Corporate to the information set 
Corporate to the schedule indicated at 3303 to be Business Hours. When the 
user clicks on box 3303, the entire list of defined schedules is shown, and the user may select 

25 one or add a new name. When the user clicks on Definition button 3305, window 3201 
for the selected policy is displayed. If a new name is being added, the user fills in window 
3201 as required for the new schedule. In terms of FIG. 30, selection of a schedule in FIG. 33 
causes a field ScheduleDef ID in PoliciesAccess table 1611 to be filled in with the 
identifier for the entry in ScheduleDef init ion table 3023 which contains the schedule's 

30 name in its Name field. If the schedule name is new, a new entry is added to table 3023 for 
the new name. If a rule is added or modified, then ScheduleRules table 3025. is modified 
as well. 
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User interface for attributes: FIGs. 34-37 

The user interface for attribute definition and assignment is similar. HG. 34 shows a wmdow 
3401 which lists the presently-defined attributes of the tpiality of service (QoS) type. These 
attributes determine how much bandwidth will be available to an acc^ being made accord.ng 
to a given policy. At 3401 are listed the attribute labels or names, here, four QoS atmbutes a« 
defined, three for ba™lwidthamounts(Hi9h, Mediun,, Low), and one (Top Priority) 
for priority in case of conflicts. All of these attributes have a precedence of 0, as shown at 
3405 Tite bandwidth attributes are all defmed by the Bandwidth feature, as shown at 3407. 
Valuel for each attribute is defmed at 3409. Only Top Priority hasaValue2. As 
specified in window 3401, the QoS attribute High receives a maximum bandwidth of 512000, 
Medium a maximum bandwidth of 64000, and LOW a maximum bandwidth of 32000. W.th 
TOP priority, the priority specified for the attribute must lie bepveen the values 
specified for valuel and Value2. The information m window 3401 comes of course fi^m 

tables 3005, 301 1 , and 3009. 

FIO 35 shows window 3501 used to assign a QoS anribute to a user group, information set, 
si«' or service. In subwindow 3503 is shown how the QoS bandwidth attributes Mediutn, 
Hioh and LOW (3509) have been assip«d u> the sabjects World Wide Web service, file 
ttansflr service, and remote access service respeofively (3511) tor all user groups (3507) and 
how the QoS priority attribute High has been assigned to the subject rinanca user group 
T„e different assignments reflect the fact that bandwidth is an attribute of a communications 
service, while priority is an attribute of a user of the communications service. Thus, wtthtn the 
bandwidth available for the Web service, members of the Finance us« group will have ta^ 
priorities. AS shown by this example, more than one action attribute may apply to a pohcy. 
Further assignments if attributes to subjects can be made by selectmg user groups and subjects 
from subwindows 3513 and 3515 respectively. 11.. selections made in this window are of 
course appUed to table «tributeAssi,n,.ents 3007. Wmdow 3503 can fi^rther be used 
in tite same general ftshion as window 3102 to reach the windows ^ to defme attnbute 
labels and features. 

Fig 36 shows the window 3601 used to read, modify, or make an entry in Attribute 
labels table 3011. Here, the entry being read is for the Medium QoS bandwidth attnbute. 
At 3603 are shown the values of the entry's Label, Descriptior^, and Label 
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Precedence fields. An administrator with the proper access rights can of course change the 
values of these fields via window 360 L At 3605 is shown information from the entry in 
Attributes table 3011 for the attribute associated with the label. There is showoi the 
current value of Valuel in the entry and the name of the feature. The feature name of 
5 course comes from AttributeFeatures table 3009 for the attribute. Again, these values 
may be edited via window 3601. Button 3607 is used to view a window that shows the 
complete contents of the feature's entry in AttributeFeatures table 3009. 

FIG. 37 shows that window. Window 3701 is the window used to define new features for a 
10 given class of attributes and new classes of attributes. The window of course works on the 
values of an entry in AttributeFeature table 3009. Box 3703 is a hst of the classes of 
attributes; new classes may be defined by adding to the list. Box 3705 is the name of the 
current feature; between them, the class and the name, con-esponding to the fields Class and 
Name in the entries in table 3009, uniquely identify an entry. In this case, the entry is for the 

* 

15 QoS Priority attribute. Description box 3707 contains the value of 
Description in the entry being examined. 3709 indicates which value type the feature 
has, here a pair of values, as indicated in FIG. 34. At 3711 are shown the current settings of 
the fields Feature Precedence and Value Precedence, and at 3713, any 
restrictions will appear. 

20 

Improvements to the generalized policy server 

The following discussion will begin with the protocol employed in a preferred embodiment to 
transfer information between a policy-enabled component and the generalized policy server 
and will then deal with the techniques used in a preferred embodiment of the access control 
25 system to permit administrators of the access control system to define their ovm methods for 
gathering information about a user and simply providing the information to the policy-enabled 
component or using the information to authenticate the user or to determine membership of the 
user in a user group. 

30 Treating access requests as database queries: FIGs. 38-40, 54 

FIG. 38 is a block diagram of a system that incorporates the improvements to the generalized 

policy server disclosed herein. In FIG. 38, components of the access control system that were 

disclosed in the parent or grandparent of the present application have the reference numbers 
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they had in the figures for the parent and grandparent. Hie improved protocol 381 1 transfers 
information between a pohcy-enabled component 2609 and a generalized policy server 2617. 
In most cases, the protocol will be carried on a network that comiects component 2609 and 
server 2617. 

In the improved protocol, the access request from policy enabled component 2609 takes the 
form of a standard SQL query. The response to the query from generalized policy server 2617 
depends of course on the contents of the query; at a minimum, the query result mdicates 
whether the access request is aUowed or denied. Within generalized policy server 2617, the 
queries are interpreted by a new proxy in proxies 203 1 , namely virtual database (VDB) service 
3813 VDB service 3813 emulates an SQL database server; in the preferred embodmient, it 
emulates either an SQL server that uses the well-known TDS protocol or an Oracle® database 
server that uses the well-known TNS protocol. Of course, in other embodiments, VDB service 
3813 could emulate any mechanism that receives an input and selects a rowset in response to 

the input. 

AS previously explained, a proxy is software in general policy server 2617 that intercepts 
traffic for a particular protocol. The proxy 'understands' the protocol that it is intercepting and 
can -obtain the information required to identify the resources being accessed and/or to 
authenticate the user from the messages that are being exchanged during the session. The 
proxy provides the information it has obtained from the session to evaluator 2036 to decide 
whether the user has access to the infomiation resource. Evaluator 2036 uses the compiled 
MMF version 2301 of the policy DB to make the determination. In the case of VDB service 
3813 VDB service 3813 does not intercept traffic, but simply receives messages m the 
protocols used by the database systems which VDB service 3813 emulates, interprets a query 
contained in a message to obtain the infomiation required to obtain a result, and then returns a 
message containing at least the result to policy-enabled component 2609. 

The virtual database — ^FIG. 54 

Because VDB service 3813 emulates a relational database protocol, the information which is 
being queried appears to be organized into a table which has a row for each potential 
user/potential resource combination for the resources controlled by policy-enabled component 
2609 and columns tiiat defme fields in the rows. Each field in a row contains the row's value 
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for the column to which the field belongs. Queries on relational databases are often written 
using the SQL language. An SQL query on a relational database table has the general form: 

SELECT <field name list> from <relational database table name> 
5 WHERE «<fieldname,value pair>,operator> list> 

To take a simple example, if each row of a table AccountBalances has three fields, 
DepositorName, AccountlD, and Balance, each of which contains what its name 
indicates, a query that obtains the account balance for the depositor "R. Date" and the account 

10 id"549362" looks like this: 

SELECT Balance from AccountBalances 
WHERE DepositorName=' R. Date' AND 
AccountlD = '549362' 

15 

The WHERE Clause indicates the fields whose values will be used to select the records of 
interest in the table and how those values will be combined; the SELECT clause indicates 
which fields of the selected records will have their values returned by the query. Thus, in the 
above example, if there is a record in the table AccountBalances which has a 
20 DepositorName field with the value "R.Date" and an AccountlD field with the value 
"549362", the query will return the value of the field AccountBalances . 

VDB service 3813 is termed a virtual database service because the queries are made on a 
virtual relational table instead of a real one. The reason for this is that the queries dealt with by 

25 VDB service 3813 are made to find out whether the access policies in policy database 3825 
will permit a user who is requesting access to an information resource to have access to the 
information resource. A real relational database table for such queries would have to have a 
row in the table for each <potential user, information resource> pair, since any of the potential 
users may request access. In most applications the real relational database table would not 

30 only be unacceptably large, it would be undefinable, since there would be no way of knowing 
who all the potential users were. 
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FIG 54 shows virtual relational database system 5401 with VDB service 3813 and virtual 
relational database table 541 1. Virtual relational database table 541 1 does not really exist, but 
appears to exist to the applications that make queries on it. From the application's pomt of 
view application, virtual relational database table 5411 works exactly like a real relational 
database table 54 1 1 . Virtual relational database table 541 1 appears to include some number of 
virtual rows 5413(0..q), each of which has a number of fields 5415(0..p). When a user makes a 
query on virtual table 541 1, the queryls WHERE clause detemiines which of the rows 5413 is 
selected and the SELECT clause determines which fields 5415 of the selected rows are 

returned. 


3 


Of course, the rows specified by the query and the returned fields are as virtual as table 5411. 
VDB service 3813 is able to respond to query 5403 even though table 5411 does not exist 
because it is able to use the information in the query's WHERE clause to locate and retrieve 
the results specified in the SELECT clause in one or more infommtion sources 5409. Having 
retrieved the results. VDB service 3813 builds a constructed row 5417 corresponding to 
virtual row 5413(i) selected by the query. Constructed row 5417 includes at least actual fields 
5419 for the results that are to be returned for the query. Constructed rows 5417 are built for 
each query, and only as many are built for each query as are needed for the rows of the virtual 
table specified by the query. Information sources 5409 may include information sources local 
to VDB service 3813 or non-local information sources, and may even include other databases. 

In the embodiment of virtual relational database system 5401 employed in generalized policy 
server 2617, policy-enabled component 2609 responds to a request by a user to access a 
resource by making a query to the virtual relational database table PolicyEval . The 
SELECT clause specifies at least a field which indicates whether the user has access to the 
resource The WHERE clause specifies infomiation which pemiits generalized policy server 
2617 to determine whether the user indeed has access. In a presently-prefenred embodiment of 
policy server 2617, the infomiation specified in the WHERE clause may come from policy- 
enabled component 2609, from evaluator 2036, and/or Authentication coordinator 3829. 
Authentication coordinator 3829 will be explained in more detail later. Depending on the 
query various fields of the user's constructed row 5417 are returned to policy-enabled 
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component 2609. Other embodiments of VDB service 3813 can of course use any mechanism 
which obtains and returns the information necessary to answer the query. 

An interesting consequence of the fact that the information in the WHERE clause in virtual 
5 relational database system 5401 is applied to information sources 5409 instead of to values of 
fields in a relational database table is that a value in a WHERE clause may be compared with 
values obtained from an information source 5409(i) in ways that are not available in standard 
relational database systems. For example, a user may belong to a user group that has access to 
an information resource if the user's IP address is within a range of IP addresses; the 

10 information source may define the range of IP addresses directly, and when the WHERE clause 
is evaluated, VDB server 5407 simply determines whether the IP address in the WHERE clause 
is included in the range. The same technique can be used with pattern matching. For instance, 
a user may belong to a user group if the user's email address is a company email address. If 
the company's email addresses all have the form <any strmg>@companyxom, then VDB 

15 server need only determine when it evaluates the WHERE clause whether the user's email 
address niatches the pattern *@cow/7a«y.co»i. 

Queries in policy-enabled component 2609 

Continuing in more detail, there are two ways in a preferred embodiment in which the 
20 capability of making queries to VDB service 3813 can be included in a policy enabled 
component. One way. is to add the necessary queries to VDB service 3813 to code executed by 
the policy-enabled component, for example Web application or server 3803, This works with 
any policy-enabled application and permits control of access of any entity that is manipulated 
by the policy-enabled component, as described in the parent of the present patent application. 
25 For example, the entity for which access is controlled may be a field in a document. 

The other way is to make the queries from a policy plug-in. A policy plug-in is an addition to 
an application program which permits the application program to perform policy evaluations. 
For example, many Web applications have provisions for the use of policy plug-ins 3805. If a 
30 policy plug-in has been provided for the Web application, the server providing the Web pages 
to the browser invokes the plug-in when it receives the URL of the next Web page to be 
fetched from the browser. When the plug-in is executed, it determines whether the browser 
may access the Web page and the server provides the Web page to the browser only if the 
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policy plug-in so indicates. Where access control is being done by generalized policy server 
2617, the plug-in makes the queries to VDB service 3813 that are required to determine 
whether the browser may have access. As indicated in FIG. 38, policy plug-ins 3805 in a 
preferred embodiment of system 3801 may be load-balancing, i.e., they may have access to a 
number of different generalized policy servers 2617 and will address a given query 3811 to the 
one which is currently least-loaded. This is of course possible in generalized policy server 
2617 because each of the generalized policy servers in the access control system has an 
identical policy database 3825 and because the generalized policy servers in the access control 
system are authenticated to each other, making it possible for one generalized policy server to 
trust information obtained from another generalized policy server. 


A policy-enabled component needs no special software to make queries of VDB service 3813. 
All that is required is access to a utUity program which turns a query into a message that is 

,5 directed to VDB Service 3813 and that belongs to a protocol which can be interpreted by one 
of the database systems that VDB service 3813 emulates. Such utility programs are widely 
available FIGs. 39 and 40 provide examples of how queries made to VDB service 3813 
appear in programs executed by policy-enabled component such as a Web server or application 
3803 or policy plug-in 3805. FIG. 39 shows high-level interface 3901. 

20 ConclavePolicyAllowed ( ) 3903 is a fimction that constmcts the SQL query that is used 
to perform the access check, sends the query to VDB semce 3813, and receives and returns 
the resuh If the result is "Yes", indicating that access was allowed, high-level interface 3901 
executes branch 3905; otherwise, it executes branch 3907. The contents of these branches 
depend of course on how the program for application 3803 or policy plug-in 3805 is to respond 

25 to allowance or denial of access. 

FIG. 40 shows a preferred embodiment of ConclavePolicyAllowed ( ) 3903. At 4003, 
variables are set which will give the policy-enabled entity 2609 access to a generalized policy 
server 2617. At 4005, the access is set to the default value "No", so that no access wUl be 
30 granted if VDB Service 3813 fails to respond. At 4007. the source and destination IP 
addresses for the access request, the destination port, and the URL of the resource bemg 
accessed are assigned to variables. At 4009, the SQL query is constructed. It uses the standard 
SQL form. The query selects the value of the field isAllowed in a row of the relational 
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table PolicyEval. PolicyEval appears to have a row for each potential user of the 
resource controlled by policy-enabled component 2609, -with a row being selected by the 
values specified in the WHERE clauses and the IsAllowed field for the selected row 
indicating whether that user is permitted access. In fact, however, as pointed out above, 
5 PolicyEval is virtual, that is, the user's "row" is eissembled in response to the access 
request. Here, the WHERE clauses are made using the variables set at 4007 and thus specify 
the user by means of a source IP address and the resource by means of a destination IP address, 
a destination port, and a resource name. As explained in the grandparent of the present 
application, evaluator 2036 can use this information to determine which user groups the user 
10 belongs to and which information sets the resource belongs to. Given this information, 
evaluator 2036 further determines from the access policies that apply to those user groups and 
information sets whether the user specified by the source IP address is to be permitted access to 
the resource specified by the destination IP address, destination port, and resource name. 

15 If the user identification information isn't sufficient to specify a user group which gives the 
user access to the resource, the As kClient For Identities WHERE clause indicates 
that evaluator 2036 may use ATS 2039 to obtain more user identification information from the 
user's UIC, as described in the parent of the present application. 

20 At 401 1 , the object needed to make the connection to VDB service 3813 and the object needed 
to hold the query results are set up and the connection to VDB service 3813 is established 
using the variables set at 4003. At 4013, the query specified at 4009 is performed by VDB 
Service 3813 in the .policy server specified at 4003. At 4015, if no errors occurred in making 
the query and the query had a non-empty result, then the result of the query (i.e., the value of 

25 IsAllowed) is in the first element of the record set. This value is returned by 
ConclavePolicyllowed. If the query failed, the value returned is the value assigned at 
4005. At 4017, the connections to the record set and the policy server are closed and the 
objects involved in the coimections set to null values. 

30 Details of the PolicyEval virtual relational database table: FIGs. 41-43 

FIG. 41 shows the schema of the PolicyEval table. The schema of a real database table is 

the definition of the table that is used by the database system. For PolicyEval, it is the 

definition used in policy-enabled component 2609 and VDB service 3813 to indicate how the 
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values needed to do the policy evaluation are arranged in query 3811. FIG. 41 shows the fields 
that are available in a preferred embodiment for use in the SELECT and WHERE clauses of 
the queries provided to VDB server 3813. Some of the fields are used primarily in custom 
authentication and will be explained in more detail there. When a field is used in a SELECT 
clause, VDB Service 3813 sets the field's value, either using information received firom 
evaluator 2036 or information received in the query. When a field is used in a WHERE clause, 
policy-enabled component 2609 sets the field's value. As will be seen firom the following 
tables, some of the fields are SELECT only, while others are WHERE or SELECT. The query 
must provide values for some of the WHERE fields in order for a policy evaluation to occur; 
with others of the fields, default values are used when none are provided by the WHERE field. 


SELECT ONLY 


IsAUowed 4103 


PolicySet 4105 


HasExpireTime 4107 


ExpireTime 4109 


ExpireSeconds 
4111 


ReasonCode 4113 
Reason 4115 


VARCHAR( 1 ) 


INTEGER 


VARCHAR( 1 ) 


DATE 


LONG INTEGER 


INTEGER 
VARCHAR(254) 


Contains 'Y' or 'N' to show whether the user may 
access the requested resource, where Y: Yes and 

N:No. ^ — 


The identifier of the current version of the policies 
used by the Policy Server to perform the evaluation 
This is incremented each time an "Apply Changes" 
is performed and the MMF files are recompiled. 
This can be useful if the policy-enabled application 
is caching decisions and needs to refresh/reset the 
cache when the database changes. 


Contains 'Y' or 'N', where Y:Yes and N:Np, 
depending on whether ExpireTime has a valid value. 
Always ignore the ExpireTime value if this column 
contains 'N\ 


The date and time after which another evaluation 
should be done to verify that access is still permitted 

tn the requested resource. 


The number of seconds until the policy decision 
expires (per schedule constraints). Can be used 
instead of ExpireTime for more efficient 

implementations^ 

Code for evaluation decision reason 

Descriptive text for evaluation decision reason (for 
max performance, use ReasonCode only unless 
debue&inj 
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SELECT ONLY 




cvai 1 imeMamp 4 1 j j 

DA YE 

^^^T^ .J A _1 .A.* .A I'll 

The date and time at which the policy evaluator 
made the decision 

AuthCode4t49 

VARCHAR(254) 

Digital signature for use in verifying that the 
response was provided bv a trusted Policv Server 

MaybeList 4151 

VARCHAR(254) 

Comma delimited list of authentication types that 
may be used to access the requested resource. 
Generally mdicates to PPI or application what 
information needs to be collected from the user for 
authentication. 

/\LLriDiiiei>ianic 

V AKL^rlAKvJ 

Can be used to get any number of attribute 
name/value pairs (one per row) instead of using 
cookie 


\/ A D/^LI A D/\ 

V A KCrlA K^^ J 

Can be used to get any number of attribute 
name/value pairs (one per row) instead of using 
cookie 


UN 1 CfUCIS. 

wnen multiple laentities exist, this is a sequence 

number 

Identity Type 4161 

VARCHARO 

The type of identity used to authorize the access 

IdentityIsValid4163 

VARCHAR(l) 

Simple 'Y\or 'N' to determine whether the 
authentication succeeded (note that you can be 
denied access even if the authentication succeeds) 

IdentityAuth Status 4 1 65 

INTEGER - 

Response code returned bv authentication module 

IdentityAuthStatusDesc 
4167 

VARCHAR(254) .. 

Descriptive text associated with code above 


WHERE OR 

m 

SELECT 



(igDescmDtion§^:i!c^ss?^|yj§^^ 

Application 4137 

VARCHAR(254) 

Name of application making query. Note that 
multiple servers/services can identify themselves as 
the same application. 

SourcelP 4119 

VARCHAR{25) 

IP Address in dotted notation. Used if policy is by 
IP address (network or application queries) . 

DestinationIP 4121 

VARCHAR(25) 

IP Address in dotted notation. Only used for 
network resource queries (instead of Application). 

Cookie 

VARCHAR(254) 

HTTP standard cookie including identity and 
attribute information. PS will verify signature and 
expiration. In SELECT, this is a request for a new. 
cookie to be issued by the PS. In WHERE, this is a 
previously set cookie passed in by the application for 
use in the evaluation. 

SourcePort 4123 

INTEGER 

Defaults to zero if no port number is provided in the 
where clause. Only used for network queries 

DestinationPort 4125 

INTEGER 

Used in network queries where Application is not 
present. Defaults to 80 (HTTP) if no port number is 
provided in the where clause. 

EncryptionAlg 4127 

INTEGER 

Used in VPN queries. Defaults to 64 (3DES) if no 
algorithm is provided in the where clause. 

AuthenticationAlg 4129 

INTEGER 

Used in VPN queries. Defaults to 2 (DSS 
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WHERE OR 


IPProtocol 4131 


Resource 4135 


Identity 4117 


lncludeQoS4l39 


INTEGER 


Used in network queries. Defaults to 6 (TCP) if no 
irotocol is provided in th e wliere clause. 


VARCHAR(254) A string that identifies which resource being 

' requested 


VARCHAR(255) 


VARCHAR(1) 


IncludeScheduies 4141 VARCHAR(l) 
lnciudeldentityStore4143 VARCHAR(1) 


AskClieniForldentities 
4145 


VARCHAR(l) 


Actual string encoded value of the Identity (Select) 
or identity information collected from the user 
WHERE) 


f v/nCiSs^j — — -— — — 

Used by network/VPN devices. Is a QoS decision 
included in the evaluation? 'Y^es or 'N'o 

Defaults to ^N^ (improv es performance) 


Are schedules included in the evaluation? ' Y'es or 
'N'o 


Defaults to (improve s performance) 

Are identities cached in the users' identity store 
(generally provided by UIC) to be used in the 
evaluation? 'Y' or 'N' 

Defaults to 'Y^ 


Is the identity client (UIC) asked for identities? ' Y'es 
or 'N'o 

Defaults to 'N' 


10 


15 


FIGS 42-44 show some examples of queries and fteir result. In FIG. 42. at 4201. query 4203 
rewms detailed infoimation about the results of the policy evaluation by specifrmg the 
Policyset, Ha.ExpireTime, ExplreTlme, and Reason fields in the SELECT 
statement in addition to I sAl lowed . The results, at 4205. show that flte policy is allowed, 
that the policy under which it was allowed belong to policy set 56, and that that policy has no 
expire time, which makes the value in ExpiroTime meaningless. Since the access ts 
allowed, there is no value in Reason. 

At 4207 is seen a query 4209 that only returns the result of the policy evaluation and the 
reason as shown at 42 1 1 . At 42 1 3 is shown a query that selects all fields of the row. and thus 
the re^ value contains the values of all of those fields, with default values being supphed 
where the field has a default value and no value is supplied in the WHERE clause. Thus, the 
field IncludeQoS will have the default value "N". At 4215, finally, is shown a mmimum 
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query. . The WHERE clauses contain only the minimum infomiation needed to specify a user 
group and a resource set. All other field values take their default values. For example, the 
encryption algorithm used will be the default 3DES algorithm. 

FIG. 43 shows how queries can be used to obtain identification information about the user who 
is being allowed access. At 4301, a minimal set of WHERE clauses is used in query 4303, but 
the SELECT clauses include I dent Type, IdentGroup, and IdentValue, As shown 
at 4305, access is allowed by three different identification values for the user. At 4307, query 
4309 provides values in its WHERE clause for the IdentType and IdentValue fields, 
and the policy evaluation is dorie using those values, as shown by result 431 1. At 4313, query 
43 15 specifies that the values to be used for user identification are to be obtained from a cache 
of user identities which is maintained in policy database 3825. 

To see what the identity store contains for IdentType and IdentValue, the query 
15 includes those fields in the SELECT clause. Result 4317 shows the values for those fields that 
are contained in the identity store. 4319, finally, shows how a query 4321 can be used to 
specify that certain information in the identity store be excluded when the identification of the 
user is determined during the policy evaluation. 

20 Overview of custom user information retrieval: FIGs. 38 and 44 

Before the access control system in which the present invention is implemented can grant a 
user access to an information resource, it must do two things: 

• authenticate the user, that is, determine that the user is the entity it claims to be; and 

• make a user group membership determination^ that is, determine whether the user's 
25 user group memberships sure such that the access policies for the information resource 

permit the user to access to the information resource* 
Both of these operations require information about the user. In the access control system 
described in the grandparent of the present patent application, both the kinds of information 
that could be used for authentication and user group membership determination and the sources 
30 of that information were predefined; in the access control system described in the parent of the 
present patent application, system administrators could define information to be used to 
determine user group membership, but the sources of that information were still predefined. 
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In the access control system of the present patent application, these limitations have been 
overcome by means of techniques for custom user information retrieval. These techniques 
permit administrators of the access control system in which the present invention is 
implemented to define how and from what sources information about the user is collected 
when an access request is made and how the information is used in comiection with the access 
request. In a preferred embodiment, generalized policy server 2617 can use the collected 
information in any of three ways: 

• to authenticate a user; 

• to make user group membership detenninations; 

. as part of a dossier, that is a list of information which generalized policy server 2617 
provides to policy-enabled component 2609 from which the access request came when 

the access request is granted. 
A given item of information that is obtained by custom user information retrieval may be used 

for one or more of the above purposes. 

. Some examples of how custom user information retrieval may be used are the 
following In many cases, users who make requests to access information resources 
have usemames and passwords on systems that are accessible to generalized pohcy 
server 2617; generalized policy server 2617 can authenticate a user by requestmg a 
user's user name and password from the user, applying the user name and password to 
the system, and seeing whether the system responds as it should when the user name 
and password are known to the system. 
. A user who requests access may have information on a database external to but 
accessible by generalized policy server 2617 which is accessible to the access control 
system; generalized policy server 2617 can retrieve the information from the database 
and use it to determine user group membership. 
Generalized policy server 2617 can provide any material retrieved from such a database system 
to policy-enabled component 2609 as part of a dossier. 

How custom user information retrieval is done in a preferred embodiment is shown in 
overview in HGs. 38 and 44. Beginning with FIG. 44, FIG. 44 shows policy database 4401 
from which the MMFs of policy database 3825 are compiled. Components of policy database 
4401 which were included in the policy databases used in the parent and grandparent of the 
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present application have the reference numbers they were given in those applications. The new 
component of policy database 4401 is definitions 4403 of custom user information retrieval 
methods. Each custom user, information retrieval method specifies a method used when a user 
requests access to an information resource of retrieving information about the user and using 
the information to authenticate the user, determine the user's membership in a user group, or as 
part of a dossier for the user. The specified method rnay include queries of databases or other 
sources external to policy server 2617. In the following, a definition of a custom user 
information retrieval method is termed a custom authentication type. This terminology is 
historical and should not be taken to suggest that the information retrieved by a method defined 
by a custom authentication type can be used only for authentication. User groups for which 
members are determined in whole or in part by using a method defined in. a custom 
authentication type will be termed hereinafter custom-authenticated user groups. 

Policy server 26 1 7 gathers the attribute values needed to determine whether a user belongs to a 
custom-authenticated user group in a fashion which resembles the description in the 
grandparent of the present application of how user authentication information is gathered via 
the User Identification Client. When a policy-enabled component 2609 makes an access 
request for a user and resource to server 2617, server 2617 proceeds conceptually as follows: 
it detemiines from access policy 307 in database 4401 what access policies apply to the 
resource and what user groups are given or denied access to the resource by these policies. If 
the session information provided by component 2609 is sufficient to authenticate the user and 
determine whether the policies that apply to the information resource and the user's user group 
memberships give or deny access to the user, server 2617 retums one of those results to policy- 
enabled component 2609. 

If the user groups for which there are policies regarding the resource include custom- 
authenticated user groups and it is necessary to apply a custom authentication method in order 
to authenticate the user or to determine whether the user seeking access is a member of one or 
more of the custom-authenticated user groups, server 26 1 7 retums a maybe result to policy- 
enabled component 2609. The maybe result indicates that server 2617 needs more information 
about the user to determine whether the user has access to the resource. Along with the maybe 
result, server 26127 retums an indication of what information is needed from the user in order 
to apply the custom authentication method. Policy-enabled component 2609 obtains the 
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information from the user and provides it to policy server component 2617, which then uses 
the information to carry out the authentication method. The method may involve authenticating 
the user, querying external databases to obtain the attribute values necessary to determine 
whether the user belongs to the custom-authenticated user group, and or querying the external 
databases to obtain information for a dossier for the user. Policy server 2617 then uses the 
result of the custom authentication as described in the grandparent of the present application to 
determine whether the user has access to the resource. If access is permitted and there is a 
dossier, policy server 2617 returns the dossier to policy-enabled component 2609. 
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As will be explained in more detail later, portion 4403 of policy database 4401 contains the 
definitions of the queries which policy server 2617 performs on the external databases to 
determine at least in part whether a user belongs to a custom-authenticated user group. Types 
of custom authentication are defmed in database 4401 in the same fashion as user ID types 
generally, namely by any user who belongs to an administrative user group 319 for which a 
policy maker policy 306 indicates that members of the administrative user group may define 
types of custom authentication. 

Custom authentication in a preferred embodiment: FIGs. 38 and 45 
FIG. 38 shows a preferred embodiment of an access control system in which custom- 
authenticated user groups can be defined and used to control access. The components of FIG. 
38 which implement the query interface to policy server 2617 have already been discussed; the 
following components implement custom-authenticated user groups: 

• in policy-enabled component 2609: 

— authentication form 3807 and 

_ local configuration information 3809; these are used to obtain attribute values 

from the user. 

• in generalized policy server 2617: 

_ Policy database 3825, which includes compiled definitions 4403 for types of 

custom authentication; 
_ authentication coordinator 3829, which receives an indication of a custom 
authentication type and the information provided by the user from VDB service 
3813, uses the information to authenticate the user as specified by the custom 
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authentication type, and returns the result of the authentication to VDB Service 
3813. 

— authentication modules 3839(a..n), of which there is at least one for each 
external source of authorization information. An authentication module 3839(i) 
receives a query specification from authentication coordinator 3829, puts the 
query specification into the proper form for a query to the authorization 
information source, and returns the results of the query to authentication 
coordinator 3829. 

— authorization servers 3843(a..n): these are the sources of authentication 
information. . 

.— cookie manager 3817 and signer- validator 3819: these make a cookie from the 
information returned by authentication coordinator 3829 and append a digital 
signature to it. The cookie is returned to. policy-enabled, component 2609, and 
is used by policy-enabled component 2609 tp indicate to policy server 2617 that 
an access check has already been made for a user/resource combination. 

♦ * • . • 

In FIG. 45, flowchart 4501 provides an overview of how policy-enabled component 2609 and 
its coniponents interact with generalized policy server 2617 and its components to collect the 
information about the user needed to authenticate the user or to determine a user's membership 
in a custom-authenticated user group or to provide, a dossier to policy-enabled component 
2609. Flowchart 4501 presumes that the user is requesting a Web page; however, techniques 
described in the following may be used with any resource to which access is controlled by 
generalized policy server 2617. 

At 4503, the user requests access to the resource from a Web server 3803, in this case, the Web 
page, using his or her Web browser to do so. Of course, any other means of getting the access 
request to policy-enabled component 2609 may be used as well. Flowchart 4501 presumes 
that the access checking is being done by a policy plug-in 3805, but the access checking may 
be done by any program executing on policy-enabled component 2609. Thus, at 4505, server 
3803 passes the information from the session with the user making the request to policy plug- 
in 3805. 
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Policy plug-in 3805 establishes a connection to an available generalized policy server (4507). 
When the connection is established, plug-in 3805 sends a query 3811 to VDB service 3813. 
The query will include information indicating the user seeking access and the information 
resource to which access is sought. If the user has previously made the request, the query may 
also be accompanied by a cookie. The cookie is an indication of the result of the previous 
access request which has been authenticated by the generalized policy server 2617 or another 
generalized policy server 2617 which is trusted by the first generalized policy server 2617. 

If there is a cookie, VDB service 3813 reads it and compares it with the session information 
, for the current session; if they are the same, VDB service 3813 provides the information in the 
cookie to evaluator 2036. If there is no cookie, VDB service 3813 handles the query as 
previously described. If evaluator 2036 detemiines that the information identifying the user is 
enough to make an access determination and allows access (4509), branch 4511 is taken; if 
evaluator 2036 determines that access should be denied (4515), branch 4517 is taken. 
5 Otherwise, VDB service 3813 returns a maybe result and a list of the types of custom 
authentication that are relevant to the access detemunation to policy enabled component 2609 
(4520) The code in policy plug-in 4507 responds to the list by selecting one of the custom 
authentication types on it and then selecting the authentication form 3807(i) corresponding to 
the selected custom authentication type, configuring it as specified in local configuration 
so information 3809, and outputting it to the user's browser (4521). 

The authentication fomi requests the infomiation firom the user that is required for the user to 
authenticate him- or herself using the method specified in the selected custom authentication 
type The user fills in the form (4521), and the plug-in takes the information provided by the 
25 user and adds it to the query 381 1. The added information is termed herein authentication 
information and includes an identification for the selected custom authentication type and a list 
of the values received from the user in the form oi<attribute name. attribute value> pairs. The 
query then goes back to VDB service 3813 (4523). 

30 AT 4525 VDB service 3813 provides the authentication information to authentication 
coordinator 3829, which retrieves the defmition for the selected custom authentication type 
from policy DB 3805 and provides it to the authentication module 3839(i) that is used to 
perform the queries needed for the authentication. Module 3839(i) puts the query into the 
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proper form for the server 3943(i) which is to perform it and sends it to server 3843(i). When 
server 3843(i) returns the resuh, module 3839(i) makes the result, including whether the query 
succeeded, into a list of <attribute name, attribute value> pairs and returns the list to 
authentication coordinator 3829. Authentication coordinator 3829 uses the custom 

* r t 

authentication type definition to determine whether the authentication succeeded and returns 
the resuh of the authentication to VDB Service 3813. A list of <attribute name, attribute 
value> pairs containing information retrieved by the query may accompany the authentication 
result and may be used to make a dossier 3804. If the authentication result indicates success, 
VDB Service 3813 adds the identification of the custom authenticated type and the information 
returned by module 3839(i) to the other information about the user and information resource 
and resubmits it to evaluator 2036 for evaluation at 4509, with branching on the results of the 
evaluation as before. With a maybe result, VDB Service 3813 retums that result to plug-in 
3805; the list of custom authenticated types of course does not include the one that was just 
used. The above process, indicated by loop 4526, continues until evaluator 2036 either denies 
or grants access, access being denied unless evaluator 2036 finds no access policies which 
deny access by a user group that the user is a member of to the resource and at least one access 
policy which permits access by a user group that the user is a member of to the resource. 

If access is denied (branch 4517), plug-in 3805 provides an access denied screen to Web server 
38 (4541) which in turn provides the screen to the user's browser (4545). If access is allowed 
(branch 4511), VDB service 3813 determines whether there is a dossier (4537); if there is, 
VDB seiyice 3813 adds the dossier to the query resuh (4539) and passes the result and any 
dossier to plug-in 3805 (4540), which passes the session, including the dossier, back to Web 
server 3803 (4543), which in turn permits the user to view the requested Web page. 

A detailed example of custom authentication 

The following detailed example will first show the administrator's interface for defining a 
custom authentication type and the resulting custom authentication type definition, will then 
show how the custom authentication type definition is used to define a custom-authenticated 
user group, and will finally show how a user who may belong to the custom-authenticated 
user group is authenticated and how the attribute values necessary to determine the user's 
membership in the custom-authenticated user group are obtained. 
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Defining custom authentication types: FIGs. 46-48 

FIG. 46 shows window 4601 that is used in a preferred embodiment to define a custom 
authentication type. At 4603 is a field which receives the custom authentication type's name, 
here LDAP Bind. LDAP is a well-known protocol running over TCP/IP for accessing 
directories of people or other entities. LDAP Bind defines a custom authentication method 
which authenticates a user based on an entry for the user in a directory accessible via LDAP. 
At 4605 is a description of the custom authentication type. Cooke life span 4607 determines 
how long a cookie indicating authentication by the custom protocol should last, in this case 2 
hours. After expiration ofthe period, the authentication using LDAP Bind must be redone. 

in the preferred embodiment, the authentication method is implemented as one or more 
functions. The first function in the method is invoked by authentication coordinator 3829. 
Other functions in the method are invoked in the course of that fimction's execution. The code 
for the functions, i.e., the implementation of the fimctions' authentication module 3839, is 
contained in a run-time loadable module such as the .dll files used with operating systems 
manufactured by Microsoft Corporation. At 4609. the administrator defining the 
authentication method indicates which ofthe fimctions he or she is working with; at 461 1, the 
administrator indicates the name of the . dll file containing the fimctions. The settings at 
4613 and query parameters 4615 are for the fimction currently specified at 4609. At 4613, the 
administrator indicates whether the results of the fimction are required for authentication and 
whether VDB services 3813 is to include the results in the cookie it makes to represent the 
policy evaluation. 

The list of parameters 4615 specifies information that must be provided to the fimction if it is 
to authenticate the user and find the information necessary to determine whether the user is a 
member of a custom-authenticated user group in a directory accessible via the LDAP protocol. 
Each parameter on the Ust has a name (4617), a value, (4619) a data type (4621), and a 
description (4623). The parameter values can be specified in three ways: 
• as constants, for example the port number "389" 

. as values to be provided by the user for use in authenticating the user, specified by the 
notation ${<variable name>}, for example $ { PWD } . which is a password provided by 


the user; 


113 


wo 00/79434 PCT/USOO/17078 

• as patterns to be matched, with wild cards indicated by *. Thus, the pargimeter 
AtributeSearch may be matched by any attributes retumed by the directory entry 
accessed via LDAP. 

5 FIG. 47 shows at 4701 how a custom authentication type is associated with an information set 
and how an authentication form 3807 is associated with a custom authentication type. Screen 
4703 shows a hierarchy of information sets named Authenticated that require special 
types of authentication; one of the types is LDAP Bind for a service named Neptune, at 
4705. Entry 4705 represents authentication module 3839 for Neptune and LDAP Bind. 

10 At the next level down (4707) is an information set specified by WS//BindNeptune . html . 
WS indicates the application by means of which the information set may be accessed and 
BindNeptune. html the information set itself. A user wishing to access this information 
set must be authenticated and must be a member of a user group that may access the 
inforaiation set determined by the LDAP Bind custom authentication method. , Of course, if 

15 this is to work, plug-in 3805 for the application 3803 being used by the user who is attempting 
to access BindNeptune, html must have an authentication form 3807 for the information 
required to authenticate the user, in this case, to determine whether the user's user 
identification and password permit the user to access BindNeptune . html . That is 
specified at 4709. Screen 4711, finally, specifies the manner in which information may be 

20 retrieved from the application WS; again, pattern matching is used; as indicated by the 
asterisks in all fields but the URL field, the only requirement for the application WS is that 
the user access the Web page BindNeptune . html . 

Other features of the access control system that are seen in FIG. 47 are that 
25 WS//BindNeptune.html defines a virtual Web server^ i.e., any number of such 
applications that give access to information sets may run on the same physical machine, as 
long as the applications have different IP addresses, port numbers, and/or Intemet names. 
Further, as can be seen firom the Action field in screen 4711, a resource definition may 
include an HTTP verb, and access to the resource may be limited to what is provided by the 
30 verb. Finally, the length of the key used in the SSL protocol may be specified. 

Fig. 48 shows how a user group may be eissociated with a custom authentication type access 
method and how an access policy may be made giving the user group associated with the 
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.v^om au*enttcaaon ^ acc«s .o infonmUon s« associated wiA Ae custom 
authentication type. The window showing the use, groups is at 4805; user groups are defined 
hierarchically, and here there are authenticated user groups, i.e., user groups that use special 
authentication methods. Under that user group is the user ^oup that has access to 
BindNepturt., and under that user group is tire user group 4807 whose members are 
detennined using information r^deved by the LDAP Bind custom authentication type 
Patterns specifying ti>e parameter values which users who have access to ti.e directory quened 
by LDAP Birtd must have are indicated in the entry; here, tire asterisks indicate tiiat any 
person who has a name and a telephone number in the directory is a member of the u«r group 
LDAP Bind Window 4809 shows the information sets; at 4709 is tite entry for die 
Bind«aptur.e . html information set, which requires the use of LDAP Bind for access. 
The window showing the access poUcies is at 4801; access policy 4803 indicates tiiat 
infom^tion sets belonging to LOAP Bind-Neptune (which includes the information set 
provided by the appUcation WS) may be accessed by the user group Bind «eptune, whtch 
uses the custom autiientication type LDAP Bind. 

ImplementaHoa of custom aufl.«.H«..ion type defmitions 4403: FIGs. 49-50 

,„ order to assure compatibility with existing versions of the access control system ,n which 
custom authentication is implemented. custi>m authentication type definitions in a preferred 
embodiment are made using preexisting tables in the poUcy database. The tables are tire smart 
can! type and smart card definition tables, shown at 1323 in FIG. 13A, and tire proxy 
definitions and proxy parameter tables, shown at 1709 in FIGs. 17B and 17C. 

Each custom authentication type has a row in the SmartCard Types table as shown at 4901. 
Tie row specifies a type ID 4903 for tite custom authentication type, its name 4905, and a 
comment 4907 indicating its purpose. The autit^itication metitod for ttte authentication type ts 
defined using a row in the Proxy Defmitions table, as shown at 4909, and rows in the Proxy 
Pa,am«er Definitions table, as shown a. 5001. The relationship between Ute row m ttte 
SmanCaxd Types table and ti« definition of tite type's method is established by the use of 
, LDAPBindinf.eld4913ofrow4909andLDAPBindinfieId4805 ofrow4901. Tlte ote 

fields of tow 4909 include field 491 1. which is an ID number for tite metfrod. field 4915, wtach 
is a description of the mefliod, and field 4917, which specifies the nmnber of rows m Proxy 
Parameter Defmitions Table 5001 tiat are used to define the autiientication method. 
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Continuing with Proxy Parameter Definitions Table 5001, the rows shown define the method 
for the LDAPBind custom authentication type. .The rows 5001 specify a set of parameters 
5002 which are used in authentication coordinator 3829 and the relevant authentication 
modules 3839 and/or profile retrieval interfaces 3841. Each row has its own identification 
number in field 5003, the identification number of row 4909 in field 5005, which relates the 
row to its proxy definition, a name field 5007, which indicates the use of the parameter in the 
method, a description field which describes the parameter, and a value field which contains the 
parameter's value. It should be noted here that the significance of the parameters in 
parameters 5002 depends completely on the modules that use them. 

* 

A set of parameters may include a number of subsets of parameters. In most cases, a subset of 
parameters describes a query on an external data source which is cried out by an authentication 
module 3830 or a profile retrieval interface 3841. Values retumed in parameters of one 
parameter subset may be used as parameters of following parameter subsets. Parameter set 
5002 has two such subsets, named Stepl, shown at 5017, and Step2, shown at 5025, Only 
Stepl will be explained in detail. Begiiming at the top of parameter set 5002, row 5013 
indicates that the cookie that represents the access request for which parameter set 5002 is 
being provided to an authentication module or profile retrieval module is to be valid for 2580 
seconds; row 5015 indicates that there are two parameter subsets, named Stepl and Step2. 
All of the rows in Stepl have names of the form St epl /.<step name> in field 5007. 

Continuing with Stepl in detail, Stepl's parameters define a query on the LDAP 
directory which, given the userlD and password provided by the user who is making the access 
request, will return the employee's room number, work telephone, and email address. The user 
provides the userlD and password by meaiis of authentication form 3807 for LDAP Bind, and 
if the userlD and password give the. user access to the directory/ the user has been 
authenticated. Beginning with the rows at 5016, these rows specify the name of the fimction 
that will execute the step and its dlL The row at 5019 indicates that the results of the query 
executed by Stepl should be included in the cookie that represents the access request. The 
next row indicates the maximum time that execution of the query should take before the 
subprogram returns a result indicating failure. The rows with the names Stepl\Port, 
Server, User DN, and UserPWD contain the parameter values needed to locate and 
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access the LDAP directory. It should be aoted that the values for the last two rows are the ones 
provided by the user via authentication form 3807. Hie rows at 5021 indicate the parameter 
values that are to be returned by the query on the LDAP directory; it is these returned values 
which will be used to determine whether the user making the request is part of a user group 
that has access. 

Row 5025 in the Smartcard Definitions table, finally, serves to define a user who belongs to a 
user group whose membership is determined at least in part by the LDAP Bir.d custom 
authentication type. At 5027 is seen the row's ID number; at 5029 is found the name of the 
user- field 503 1 contains the ID for row 4091and thus indicates that the user is authenticated by 
LDAP Bind. At 5033 is a list of <attribute.value> pairs indicating patterns that must be 
matched by attribute values obtained by the LDAP Bind method firom the directory if a user 
is to be authenticated as the user Tony M. 

Custom user information retrieval and the query interface to the generalized poUcy 
server: FIG. 41 

Fields4117and 4151 through 4167 of row 4101 of the virtual POL ICY EVAL table provide a 
query interface in the preferred embodiment for custom user information retrieval. Contents of 
the fields are explained in detail in the discussion of FIG. 41 above. All of the fields but 
Identity 41 17 and Cookie 4157 are Select Only; Cookie is either Where or Select. Here, only 
the following will be pointed out about the fields: 

. Identity 4117, when used in a SELECT clause, returns the actual value of the user's 
identity to policy enabled component 2609; when used in a WHERE clause, it provides 
the user identification information collected by policy enabled component 2609 for a 
given custom authentication type together with a specifier for the type itself to VDB 
service 3813, which in turn passes it to authentication coordinator 3829. 
. MaybeList 4151 is the list of custom authentication types which evaluator 2036 returns 
when it finds that determining whether a user has access to a resource requires that the 
user's membership in one or more custom-authenticated groups be determined. 
. AttributeName 4153 and AttributeValue 4155 are a single one of the <anribute 
name valuO pairs returned by execution of a custom authentication type's method. If 
the method returns more than one such pair, there will be a row 4101 returned for each 
such pair. If the method so specifies, the pair will be included in the dossier. 
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• Cookie 4157 is the cookie made by VDB Service 3813 and returned to policy-enabled 
component 2609 on a first access by a user to a resource and provided by policy- 
enabled component 2609 to VDB Service 3813 on subsequent accesses; a custom 
authentication type's method may specify information to be.included in the cookie. 

5 • IdentityNumber 4159 is a sequence number that enables authentication coordinator 

3829 to keep track of a user's identities when more than , one is required for 
authentication. 

• IdentitylsValid 4163 indicates whether the authentication of the user required for a 
given custom authentication type succeeded. If it did, the values specified in the 

10 custom authentication type's method for inclusion in the cookie and/or dossier will go 

into the user's cookie and/or dossier. 

Example of custom user information retrieval: FIGs. §1-53 

In the following example, a user requests access to the information resource 
15 WS : / /BindNeptune . html. Access to this information resource is permitted to members 
of the Bind Neptune user group, as shown in policy 4803. Membership in Bind 
Neptune is determined by means of the method defmed for the LDAP Bind custom 
authentication type. As shown in proxy parameter definitions table 5001 in FIG. 50, that 
method performs a query which takes the user ID and password of the user wishing to make 
20 the access. If the user ID and password give access to the LDAP directory database, the query 
returns the user's room number, work phone, and email address. Any or all of these values can 
be used to define membership in a user group; as shown at 4807, only the work phone is used 
to define membership in Bind Neptune, with any user who has a phone number in the 
LDAP directory database being a member of the user group. A user who has access to 
25 WS : / /BindNeptune . html may thus be defined as follows: 

UG: Bind Neptune 

UG Membership: telephoneNumber=* (any telephoneNumber attribute defined wdthin 
one of the queried databases/directories) 

30 Giving a user who is a member of the Bind Neptune user group access to 
WS : / /BindNeptune . html involves the following steps: 

1. User enters URL for the resource in the user's Web browser 
(http://pluto.interdyn.com/Bi ndNeptune.html ); 
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2. Web server 3803 receives request and calls PPI 3805; 

3. PPI 3805 makes query to PS 2617, providing resource specification, etc; 

4. VDB service 3813 receives the query and calls evaluator 2036. Evaluator 2036 
responds with MAYBE response and the custom authentication type(s) that might 

i allow the user access to the requested resource; 

5. VDB service 3813 sends back MAYBE and auth type(s) to PPI 3805; 

6. PPI 3805 loads configured HTML form 3807(i) for this custom authentication type 

and displays the form in the user's browser; 

7. User fills in requested information and posts form; 

0 8. Server 3803 receives posting with the requested information and calls PPI 3805 for 

processing; 

9. PPI 3805 queries VDB Service 3813 with the requested information; 

10. VDB Service 3813 provides the custom authentication type and the information to 
authentication coordinator 3829, which calls authentication module 3839(a) for the 

5 LDAP Bind custom authentication type and provides the module with 

configured/passed-in information; 

11. Authentication module 3839(a) binds to LDAP directory 3843(a) witii 
usemame/password supplied and queries directory for attributes of tiiat user. 
Authentication success code and list of attributes are sent back to autiientication 

20 coordinator 2839, which in turn returns tiiem to VDB service 3813; 

12. VDB service 3813 calls evaluator 2036 with user name and attributes. Evaluator 2036 
returns ALLOW based on telephoneNumber attribute and cookie for "setting" on 

browser; 

13. VDBservice 3813 retiims allow to PPI 3805. which displays the originally requested 
25 page. 

In tiie above example, tiie metiiod defmed by the custom autiientication type uses tiie attnbutes 
returned by tiie query on tiie LDAP data base only to determine user group membership; tiie 
metiiods specified in otiier custom autiientication types may place some or all of tiiese 
attributes and otiier attributes returned by otiier queries in a dossier 3803 for return to 
30 application 3803. It should fiirtiier be pointed out here tiiat a preferred embodiment of tiie 
^ invention is implemented on an NT server costing $3000 and can perform tiie steps described 
above for 50-100 users a second. The chief reason for tiie speed witii which tiie steps can be 
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performed is the use of compiled MMFs 2301 in policy database 3825, as described in the 
grandparent of the present patent application. 

Continuing in more detail, when PPI 3805 receives the URL and makes the query in step 3 
5 above, the query looks like this: 

select Cookie, IdentitylsValid, IsAllowed, reasoncode, 

maybelist, cookiemodif ied 
from policyeval 

where sourceip= ' 192 . 168 . 3 6 . 215 ' 
and applications ' WS * 

and resource= • BindNeptune . html&GETSc 
192 . 168 .36 .217& 
pluto . interdyn . com&BO&O ' 
and includeeval= » Y' 
and includeidentitystore= ' Y ' 
and askclientforidentities= 'N' 


10 


15 


20 The information from which the user may be authenticated and his or her user group 
membership may be determined in the above query is simply the user's IP address in 
source ip . The resource to which the user is requesting access is defined by the application 
program from which access is being requested, WS, the URL provided by the user, and the 
specification from WS that the operation being requested on the Web page specified by the 

25 URL is the HTTP GET operation. Policy plug-in 3805 is configured with a list of generalized 
policy servers 2617 which it may query; policy plug-in 3805 selects a generalized policy server 
2617 in a manner that balances the loads on the policy servers on the list and sends the query to 
that policy server. 


30 The response to the query will contain a cookie if access is allowed, will indicate whether the 

user's identity is valid, give a reason for the valid identity, and will include a maybe list if it 

turns out that a custom authentication type is involved in gaining access. A custom 

authentication type is in fact involved, so the response looks like this: 

Cookie = ;IdentityIsValid = 

Is Allowed = N; ReasonCode = 118; 
MaybeList = LDAP Bind; CookieModif ied =N 

The null value for Identityls Valid indicates that the authentication of the user did not 
succeed; consequently, no cookie is returned and no access is allowed. The reason the 
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authentication did not succeed is that a custom authentication type, LDAP Bind, is involved, 
and the custom authentication type's name is reUimed in the maybe list. ' 

Policy plug-in 3805 responds to the result of the first query by sending authentication form 
5 3807(i) for the type LDAP Bind to the user. Form 3807(i) is formatted as specified in local 
configuration information 3809. The resulting screen 5101 that is used in a preferred 
embodiment is shown in FIG. 51. A request for information about a user from a directory that 
obeys the LDAP protocol must include the user's user name and password; the form collects 
that information at 5103 and 5105; the information is sent to PPI 3805 when the user presses 
10 log-in button 5107. 

To deal with the case where the maybe list has more than one custom authentication type name 
on it, PPI 3805 is configured with an ordered list of custom authentication types; the custom 
authentication types from the maybe list are handled one at a time by PPI 3805 in the order in 
1 5 which they appear on the ordered list. 

PPI 3805 uses the information from the user to make a new query 5201 to VDB service 3813; 
that query is shown in FIG. 52 and its result in FIG. 53. Query 5201 differs from the first 
query to VDB Service 3813 in that a new field has added, namely identity field 5203. The 
contents of this field contain the information which VDB service needs to have authentication 
coordinator 3829 cause an authentication module 3839 collect the user information needed to 
authenticate the user and to permit evaluator 2036 to determine whether the user belongs to a 
user group whose members may access the infonnation resource. In particular, identity 
field 5203 contains the URL for the resource to which access is being sought at 5204, the name 
of the custom authentication type whose method will be used at 5205, the user name 5207 
provided by the user at 5103 in authentication window 5101, the password 5209 provided at 
5105 in window 5101, and an indication at 5211 of the action that caused the user name and 
password to be sent, namely, that the user pushed button 5107 on the screen. 


20 


25 


30 


VDB Service 3813 responds to query 5201 by processing the WHERE clause fields 
sourceip through askclientf oridenties and then passing the contents of 
identity field 5203 to authentication coordinator 3829, which in turn fetches proxy 
parameter defmition 5001 for the LDAP Bind custom authentication type from policy 


121 


BNSDOCID' <WO 0079434A1.I > 


wo 00/79434 PCT/USOO/17078 

database 3825 and invokes the authentication module 3839(i) specified therein using the user 
id and password specified in fields 5207 and 5209. As specified in parameter definition 5001, 
authentication module 3839(i) performs a query on the LDAP server which returns the user's 
room number, work telephone number, and emdl address. As specified at 5023 in parameter 
5 set 5002, the query must succeed if the user is to be authenticated. Authentication module 
3839(i) indicates to authentication coordinator 3829 that the query has succeeded and returns 
the data returned by the query to authentication coordinator 3829. Authentication module 3839 
passes both the result and the returned data to VDB Service 3813, which provides the returned 
data to evaluator 2036 for use in determining whether the user belongs to the Bind Neptune 
10 user group. Here, the returned data includes the user's telephone number, which is all that is 
required to establish membership in Bind Neptune, so evaluator 2036 indicates to VDB 
Service 3813 that the access is allowed. 

VDB Service 3813 now has all the information it needs to make and return a result for query 
15 5201. Result 5301 is shown in FIG. 53. Most of the result consists of Cookie 5303, which 
is returned only if the access request succeeds. Cookie 5303 contains a description of the 
access request including user information provided by the user and retrieved by the custom 
authentication method. Cookie 5303 further contains a digest at 5305 and the. digital 
signature of generalized policy server 2617, These components make alterations of the 
20 contents of Cookie 5303 detectable and make it possible for one pohcy server 2617 to accept 
a cookie from another policy server whose signatxire it recognizes. At 5309, the results 
indicate that the user has been authenticated, at 5311 that the access has been allowed, and 
since access has been allowed, MaybeList is empty, as indicated at 5313. When policy 
plug-in 3805 receives the above result, it permits application 3803 to display the page 
25 http!//pluto.interdvnx Qm/BindNeptune,html. 


Dossiers 

r 

As will be immediately apparent from the foregoing detailed example, custom authentication 
methods may be defined for collecting any information which a user can provide via an input 
30 device or which can be obtained from an information source accessible to generalized policy 
server 2617. In the example, the information collected from the user was used for 
authentication and the information obtained from the LDAP directory was used to determine 
the user's membership in a user group, but there is no requirement that this be the case. A 
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custom authentication method can be used as well simply to collect information about a user at 
the time that the user requests access to a resource and provide the information to policy- 
enabled component 2609. The information can come from any information source for which 
an authentication module 3839 or a profile retrieval module 3841 can make queries. 

The mechanism by which VDB service 3813 provides the information retrieved by a custom 
authentication module to policy-enabled component 2609 is dossier 3804. A dossier is simply 
the list of attribute-value pairs returned in fields 4153 and 4157 of the query. When the values 
returned by custom authentication method are to be included in the dossier returned to policy- 
enabled component 2609, that fact is indicated in the proxy parameter defmitions 5001 for the 
method in a matter analogous to the indication at 5019 that the values returned by the query 
defined in Stepl 5017 are to be made part of the cookie returned by the query. 


15 Positive access control 

Access control heretofore has generally had a negative purpose-to make sure that a user of a 
system accesses only those information sources which he or she is permitted to see. However, 
when custom user infonnation retrieval is combined with generalized poUcy servers, the resuh 
is a broadening of the definition of access control to include access control with a positive 

20 purpose-that is, not only to make sure that the user accesses only those information sources 
which he or she is pennitted to see, but also to make sure that the user accesses those 
information sources which are most likely to be usefiil or pleasurable to him or her. 

A few examples will suffice to illustrate the principle: 

25 . An employee database in a multinational corporation can include for each employee the 

language the employee is most comfortable in; this information can be retrieved when 
the employee requests access to an information source and returned as part of the 
employee's dossier 3804 to policy-enabled component 2609, which can then use that 
information to provide a browser interface in the proper language and where possible. 

30 to provide a version of the information source that is in the preferred language. 

. A Web merchant can use the techniques described herein to make the Internet 
equivalent of the lounges and upgrades that airlines provide for frequent fliers. When a 
customer accesses the merchant's Web site, the merchant can check the merchant's 
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. database to determine how much business the customer . has done over the last six 

ft 

months and return that amount to the merchant's Web server. The Web server can user 
the amount to determine the appesirance of the Web page, to determine price discounts 
and other specials, and also to move the session to a server that will guarantee the user 
5 fast response even during congested time periods. 

A final example will show the full extent to which custom user information retrieval and 

« 

generalized policy servers broaden the concept of. authentication and access control. With a 
generalized policy server and custom user information retrieval, one could implement a lottery 
like this: an access policy is defined in the generalized policy server which gives users 
10 belonging to the user group lottery winner access to the resource lottery winnings^ which is a 
bank account containing the lottery winnings. A user is a member of the user group lottery 
winner if an attribute won lottery associated with the user has the value "Y". The value of the 
attribute for a given user is determined by a method defined by the lottery winner type custom 
authentication type. 

15 

A user plays the lottery by inputting the URL of the resource lottery winnings to his or her 
Web browser; the lottery application which receives the URL makes a query as described 
above to VDB service 3813; cvaluator 2036 determines that someone who is a member of the 
user group lottery winner may have access and returns the lottery winner type name to the 
20 lottery application, which outputs a window to the user which asks the user to input a number. 
The lottery application then makes a second query as described above which includes the 

I 

lottery winner type name and the number received from the user. VDB service 3813 passes the 
lottery winner type name and the number to authentication coordinator 3829, which provides 
the number to the type's authentication module 3839. The authentication module uses a 

25 random number generator to generate a number; if it is the same as that input by the user, 
authentication module 3839 returns the value "Yes" for the attribute won lottery, otherwise it 
returns the value "No". VDB service 3813 provides the value of the attribute won lottery to 
evaluator 2036, which uses it to determine whether the user is a member of the user group 
lottery winner. If the user is, VDB service 3813 returns a result indicating that the user has 

30 access to lottery winnings, and the user can transfer the amount in lottery winnings to his or her 
personal bank account. 
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Conclusion 

The foregoing Detailed Description discloses to those skilled in the arts to which the Detailed 
Description pertains how to construct an access control system in which access is checked by 
an SQL query on a virtual relational database table which contains a row for each potential 
user/information resource combination and how to provide administrators of the access control 
system with techniques for defining how and where the access control system collects 
information and how the access control system uses the information. The information may be 
collected from the user seeking access and from internal or external sources and may be used 
to validate the user's identity, to determine membership of the user in a user group, or to 
provide the policy enabled component with arbitrary additional information about the user. The 
inventors have further disclosed the best mode presentiy known to them of constructing the 
access control system. 

While the techniques disclosed herein for presenting an application with a virtual database 
table are particularly advantageous in access control, where the set of possible user/information 
source combinations may be very large and is often undefmable, they may be used elsewhere 
to provide simple and easily-understood interfaces to servers, to particular, they may be used 
to advantage in access control systems which do not employ access policies which define 
access in terms of user groups and information sets. Moreover, while the techniques for 
defining how and where the access control system collects and uses information work well 
with the SQL query interface used in the preferred embodiment, the techniques can be applied 
in other kinds of access control systems as well. All that is required is a way of relating the 
user to the method definition. 

The actual embodiment of the inventions disclosed herein is further greatly influenced by the 
fact that the inventions are implemented m an improvement of an existing system that must be 
compatible with older versions of the system. Other implementations of the invention will 
similarly be influenced by the constraints or lack thereof imposed upon the designers. 
Moreover, the choice of SQL as the query language is advantageous because of its wide 
distribution, but is not necessary. Other embodiments may use other query languages and may 
emulate other protocols for accessing remote databases. 
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Thus, an unlimited number of other embodiments of the principles disclosed herein are 
possible and for that reason, the Detailed Description is to be regarded as being in all respects 
exemplary and not restrictive and the breadth of the invention disclosed herein is to be 
determined not from the Detailed Description, but rather from the claims as interpreted with 
the full breadth permitted by the patent laws. 
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« 

What is claimed is: 

1 1. Apparatus for providing information in response to a query where the query and the 

2 response thereto have defined forms, the query being addressed to a database table having at 
least one row, each row having at least one named field, the query including at least one field 
name to specify the information to be provided in the response and an mdication of a manner 
of selecting a row containing the information from the database table, 

6 the apparatus comprising: 

7 a virtual database service; and 

an information source for the information to be provided which does not use the named 

9 field to identify the information to be provided, 

10 the virtual database service receiving tiie query, using tiie indication of tiie manner of selecting 

11 a row to obtain the information to be provided from tiie infonnation source, and providing the 

12 information in the response, 

13 whereby tiie apparatus presents a virtual database table of tiie form addressed by tiie query to a 

14 sovirce of the query . 

1 2. The apparams set forth in claim 1 wherein: 

2 tiie indication of a manner of selecting a row includes a selection value; and 

3 tiie information source provides a component of tiie information to be provided in 

4 response to a match between tiie selection value and a pattern that matches a plurality of 

5 values and is accessible to tiie infonnation source. 

1 3. The apparatus set forth in claim 1 wherein: 

2 the query is an SQL query addressing the database table; 


3 
4 


1 
1 

2 


the field name is contained in a SELECT clause in the query; and 

the indication of the mamier of selecting a row is contained in a WHERE clause in the 


query. 


4. The apparatus set forth in claim 1 wherein: 

the information source is an access evaluator which determines whether a user may 


* 3 have access to an information resource; 
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4 . the manner of selecting the row mcludes information from which the user and the 

5 information resource may be detemiined; and 

6 the provided information includes an indication of whether the user determined from the 

7 information may access the information resource determined therefrom. 
I 

1 S. The apparatus set forth in claim 4 wherein: 

2 the access evaluator determines whether the user may have access to the information 

3 resource by considering one or more access policies, each access policy indicating whether a 

4 user group may have access to a set of information resources and access by the user to the 

5 information resource being allowed when the access policies for the user groups to vyhich the 

6 user belongs and the sets of information resources to which the information resource belongs 

7 so indicate; and 

8 the manner of selecting the row contains membership information about the user from 

9 which membership of the user in a user group may be determined, 

*■ • * ' 

1 6. The apparatus set forth in claim 5 wherein: 

2 the access evaluator uses the membership information to determine membership of the 

3 user in a user group. 

1 7. The apparatus set forth in claim 6 wherein: 

2 the access evaluator determines that there may be a user group such that membership in 

3 the user group would give the user access to the information resource; and 

4 the provided information indicates a method of providing fiirther information about the 

5 user in a further query from which the user's membership in the user group can be determined. 

1 8. The apparatus set forth in claim 7 wherein: 

2 the further information includes authentication information which may be used to 

3 validate the user's identity. 

1 9. The apparatus set forth in claim 8 frirther comprising: 

2 an additional information source that is an authenticator, the authenticator using the 

3 authentication information to validate the user's identity. 
1 
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10. The apparatvis set forth in claim 9 wherein: 
the response to the fiirther query provides an indication whether the user's identity is 

valid. 

11. The apparatus set forth in claim 5 further comprising: 
an additional information source that is a user profile information source which 

provides additional information about the user; 

the information about the user includes a user information retrieval method 
specification that specifies how the user profile information source provides the additional 
information; and 

the access evaluator uses at least some of the additional information to determine 
membership of the user in the user group. 

12. The apparatus set forth in claim 5 fiirther comprising: 

an additional information source that is an authenticator which validates the identity of 

the user; 

the autiienticator uses the membership information to validate the identity of the user; 

and 

the access evaluator determines membership of the user in a user group only after the 
authenticator has validated the user's identity. 

13. The apparatus set fortii in claim 4 fiirther comprising: 

an additional information source tiiat is an authenticator which validates an identity of 

the user; 

tiie manner of selecting the row includes authentication mformation which the 
authenticator uses to validate die user' s identity; and 

the provided information is obtained at least in part from tiie authenticator and includes 

7 an indication of whether the user' s identity is valid. 

1 14. The apparatus set forth in claim 4 fiirther comprising: 

2 an additional information source that is a user profile information source which 

3 provides additional information about tiie user; 


5 
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4 the manner of selecting the row includes profile information gathering information 

5 which indicates to the profile information source how to gather the profile information; and 

6 the provided information is obtained at least iii part from the profile information source 

7 and includes the profile information. 
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MMF File Name 


r 


DBUsersFile 


23QI 


DBUsersTreeFile 


Contents 

Policies. User Groups, and Information Sets 2305 

Describes policy application from the User Group viewpoint. 
MapTelch DB UsefGroupl^ to a list of ResourceGrouplDs with 
flags that indicate whether the policy that relates each pair is an 

allow or deny policy. , 

Describes the user groups tree as a flattened array. Maps each 
DB UserGroup ID to a list of UserGrouplDs for parent user 
groups 


^ E^iT — I nescribes oolicv application from the Resource Group (infonna- 

DBResourcesFile 23Q9 | S^fSffinrMaps each DB ResourceGroupID to a list 

of UserGrouplDs with flags that indicate whether the policy that 
relates each pair is an allow or deny policy. 


DBResourcesTreeFile 


Describes the resource groups tree as a flattened array Maps 
each DB ResourceGroupID to a list of ResourceGrouplDs for 
parent infonnaton sets. 
User Identification Information 2313 


DBI PRangesFile 
DB DomainsFile 
DBCertificatesFile 


IP Ranges data. Maps from IPRangePeflD to the IP range data^ 
IP Domain data. Map s from DomainPeflD to the IP domain data. 


DBWindowslDFite 

DBSmartCardlDFile 

DBlPRangesByUserGroup 

File 

DBDomainsByUserGroup 

File 

DBCertificatesByUserGroup 

File 

DBWindowslDByUserGroup 

File 

DBSmartCardlDByUser 
GroupFite 

2301 


Certificate data. Maps from CertificaleDef ID to the certificate 

data. 

Windows ID data. Maps from WindowDeflD to the windows ID 

data. 

Smart card (authentication token) data. Maps from Smartcard- 

DeflD t o the authentication token data. 

Relates IP range matching criteria to user groups. Maps from IP 

Range data to UserGrouplDs. ^ 

Relates IP domain matching criteria to user groups. Maps from 
I P Domain data to UserGrouplDs. 
Relates certificates to user groups. Maps from certificate data 

to UserGr ouplDs. 21Q1 

Relates Windows IDs to user groups. Maps from Windows ID 
data to UserGrouplDs. 


Relates Smart Card (authentication token ) data to user groups. 
Maps from authentication token data to UserGrouplDs 


Fig. 23A 
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1 MMF Re Name 

Contents j 


Servers, Seivices, and Information Resources 2513 [ 

t nRRpQnnrcesBvServerlDRlG 

Relates servers to resources. Maps from ServerlDs to 1 
ResourcelDs for resources held on Ifie server identified 1 
by the Sen/erlD. 1 

DBResourcesByServieelDRIe 

Relates seivices to resources. Maps from ServicelDs to 1 
ResourcelDs for resources belonging to the service Identified | 
by the serviceiu. ^ i 

jDBResourcelDBySeivicetDRle 

R6l3tGS SerVICSS lO incir iniuiiiiduuii leouuiwo, iviopd nwiii i 

ServicelD to ResourcelD. 

DBResourceiDByNameRle 

RGi3tes ins ir names ^unud; ui icduuiuco lu icouui^^ iwa. i 
Maps from URL to resource ID. 

iDBResourcesBy Resource! DRIe 
2317 

r\**t M^/\itr/«Ao fi^ infnmn^tinn QPt^ M^D^ RpSOUfCfilD tO 1 

Keiates resources lo iiiiuiuiciuuii dcio. mop^ ncowuiudi^ *w ■ 
Resource Grouplds! | 


Servers, Services, IP Information, and Proxies 2?19 [ 

DBServerlDBylPRIe 

Relates IP addresses to servers. Maps IP addresses to j 
ServerlDs. j 

DBServerlDByNameRle 

Relates IP names to servers. Maps the IP FQDN (fully quali- 1 
tied domain name) for each server to its ServerlD. 

DBIPAndTypeByServerlDRIe 

Relates servers to their locations inside or outside to the VPN. j 
Maps ServerlD to the server's IP address and a flag indica- 

4:mm ixKAikAr ihA <aHr(rpcc Iq in<:iHp or niit^iri^ ths VPN 1 

iinQ wneiner ine auureso to moiuc ui vuioiuc vni. ■ 

DBServicelDByPortFile 

Relates services to their port numbers. Maps from SennceiD j 
to port nurnper. i 

DBServicelDByServerlDRIe 

Relates servers lo ports for services. Maps from Sen^erlD to 1 
a list of port numbers^ ^ j 

DBServicePortToProxyPortRle 

Relates service ports to the ports for their proxies. Maps from 1 
service port number to proxy port number. \ 

DBProxylDByServerlDRIe 

Relates servers to service proxies. Maps from ServerlD to j 
ProxyDeflD. __| 

DBPfoxyParamelersRIe 

Relates proxies to configuration data for the proxies. Maps 
from ProxyDeflD to options data | 
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MMF File Name 


DBAttachedNetworksBylPFile 


DBAttachedNetworksByServer 
IDFil e 

DBRoutingTableFiIe 


DBRoutingTableByServerlDFile 
DBPoinlToPointFile 


DBTrustTableFlle 


DBCertificateAuthoriliesFile 


DBTruslAuthenticationsFile 


DBTruslEncryptionsFile 


DBJavaSiteTable 


DBJavaResourceT^le 


DBJavaResourcesSetTable 


Contents 

Ac cess Filter Information 2221 
Relates network interfaces in the access filters to infomjation 
for the interfaces. Maps from the interface's IP address to in- 

terfac e infonnation. 

Relates access filters to their network Interfaces. Maps from 
Sen/erlD for the access filter to interface information. 


Describes the IP routing information for all of the access f«ters.| 
One block of in formation, 

Relates access filters to their IP routing information. Maps 
from ServerlD for the access niter to IP routing infomiation. 


Relates a point-to-point description of a networic path to data 
for the path. Maps from PointToPointID for the path to the 
as sociated data. 

SEND Information 2323 

Implements the SEND table. Maps from TrustI)eflD. incficating 
a trust level to AuthenticationlDs for user identification tech- 
niques aridEncryplio^^ 

Relates identifiers for cerfiticate authorities to their data. Maps 
from CertificateAu thoritylD to associated data. 

Relates AuthenticationlDs to infomriation about identification 
techniques. Maps from AuthenlicationID to identificaUof> 

technique information. 

Relates EncryptionlDs to infomialion about encryption tech- 
niques. Maps from EncryptionID to encryption type and 
strength information. 

Maps from names of locations to LocattonlDs. 

Maps from URLs of resources to their ResourcelDs, 
LocationlDs, and hidden flags. 


Maps from names of Information sets to ResourceGrouplDs. 
a list of ResourcelDs for all resources contained in the 
infomialion set. and a list of ResourceGroupslDs for all of the 
infonnation set's parents. 
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Schedule Rule 


Schedule Valid: 
All Day 


3203 


Starts: 


5:00 PM 



Ends: 9:00 PM 


On selected days of week: 

B Mo .B lu B We BTh B Fr □ Sa DSu 


B Weekdays 

□ Exclude Holidays 


3205 


□ Weekends 

□ Holidays 


Every week 


3207 


Every 2 ^ Weeks starting on 


6/23/99 


1 


Oh selected week of month: 

□ 1st nZud nsrd □4th □Last 


0AII year 


3209 


On selected months 

□ Jan DFeb DMar OApr □ May OJun 

□ Jul □Aug OSep □Oct □ Nov □ Dec 


Description [ 


3201 


OK 


Cancel 


Holidays 


delp 


Advanced 
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<!DOCTYPE HTML PUBLIC 
<html> 


<head> 


ft 


-//W3C//DTD W3 HTML//EN"> 


content-text/html; charsefunicode" http 
equiv="Content-Type''> 


— > 
e> 


;7_. #include file="psquery.xnc 
<title>Policy Query Example</titl 
</heaci> 

,<body> 

<hl>Conclave Policy Enabled Page<m> 
<% 


if 



^^^^^ "Yes" then 


3903 


.put the allowed action here ^his 

wr-^tc "<D>You'ye been aiiowea 
Response .write ^p^xww \^ 

page . </p> 

^'%ut <=^-"^^t,tf 5:^ve been <b>denied</b> to this 
Response. Write <p^iw4^ 

page •</?>" 
end if 

%> 

<p>&nbsp;</P> 
</body> 
</html> 


3905 


3907 


2201 


FIG. 39 
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^%%%%%%%%% %%%%%%%%%%%%%%%% 

•% File: psquery.inc 

•% Perform Policy Server 

^% Query against the current page 

•%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*%%****^*********** 
Function ConclavePolicyAllowed ( ) "1 

dsn - "ConclavePolicyServer" L ^qq^ 
dbuser = "anyone" J 
dbpass = "anything" 


4005 


•default to not allowed 
ConclavePolicyAllowed = "No 

•Get the session variables for the query 

sourcelP = Request • ServerVariables ( "REMOTE^ADDR" ) 

destIP = Request. ServerVariables("LOCAL_ADDR") 

destPort = Request- ServerVariables{"SERVER_PORT") 

resource = Request - ServerVariables ("URL" ) 

' remove any prepended slash on the URL 
if left (resource, 1 ) = then 
if resource <> "/" then 

resource = mid (resource, 2) 

end if 

end if 

'Construct the SQL query 

dbsql = "SELECT IsAllowed FROM PolicyEval WHERE _ 

r. «• C^t^r-r-raTP = » " ^ «^OUrCeIP & 


4007 


fi 


SourcelP = *" & sourcelP & _ 
AND DestinationIP = & destIP & 
AND SourcePort = 0" _ 
AND DestinationPort = " & destPort 
AND Resource = & resource & 
AND IncludeIdentityStore=' Y' " _ 
AND AskClientForldentities ='Y'" 


& 
& 
& 
& 
& 
& 


II 


tt 


ti 


> 4009 


II I 11 


set Conn = Server . CreateObj ect ( "ADODB . Connection" ) 
Set rs = Server. CreateObj ect ("ADODB. Recordset") 
Conn. Open dsn, dbuser, dbpass 


4011 


RS.Open dbsql. Conn 


4013 


if Conn. Errors. Count = 0 then 
if Not RS . EOF then 

ConclavePolicyAllowed =? RS(0) 

end if 

end if 


4015 


RS. Close 

Set RS Nothing 
Conn -Close 
Set Conn = Nothing 
End Function 

%> 

mi 


4017 


FIG. 40 
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FvairimeStainp 

Resource, 


Text 


Text 


Number 
Number 
Number 


Number 


Numbe r, 
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j ndu^deIdenfal:y5_t ore__... 
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Numb er 
Text 


4123 
4127 

4131 

4135 
4139 

4143 
4147 

4151 
4155 

4159 
4163 

4167 


FIG. 41 


BNSDOCID- cWO 0079434A1_I_> 


\ 


wo 00/79434 


PCT/USOO/17078 


48/60 


4201 


31.1.31 


32 


SELECT IsAllowed^ PolicySet, HasExpi reXime, 
PolicyEval 

WHERE SourcelP = '172 
AND SourcePort « 0 
AND DestinationIP = '172.31.1 
AND DestinationPort = 80 
AND EncryptionAlg = 64 
AND AuchenticationAlg =, 2 
AND IPProtocol = 6 

AND EvalTimeStamp = »07-JUL-1999 13:39:34' 
AND Resource ^ ' Conclave/ConclaveEval . html ' 


ExpireTime, Reason from 


4203 


IsAllowcd 

Pol icy Set 

HasExpireTime 

ExpireTime 

Reason 

\ 

56 

N 

1969-12-31 16:00:00 

None 


4205 


SELECT IsAllowed, Reason from PolicyEval 


WHERE SourcelP « •172.31.1.31' 


AND SourcePort = 0 


AND DestinationIP •172.31.1.32' 


AND DestinationPort = 80 


AND EncryptionAlg = 64 


AND Authenticat ionAlg = 2 


AND IPProtocol = 6 

4209 

AND EvalTimeStamp = ^07-JUL-1999 13:39:34' 


AND Resource = • Conclave/ConclaveEval . html ' 



42Q7 


Is Allowed 

Reason 

Y 

None 


4211 


42Ii 


SELECT * from PolicyEval 

WHERE SourcelP = •172.31.1.31' 

AND SourcePort =0 

AND DestinationIP = ' 172 . 31 . 1 . 32 ' 

AND DestinationPort = 80 

AND EncryptionAlg = 64 

AND AuthenticationAlg « 2 

AND IPProtocol = 6 

AND EvalTimeStamp = ^07-JUL-1999 13:39:34' 
AND Resource ° ' Conclave/ConclaveEval . html ' 


4213 


SELECT isAllowed. PolicySet, HasExpireTime, ExpireTime, Reason from PolicyEval 
WHERE SourcelP '172.31.1.31' 
AND DestinationIP - '172.31.1.32' 

AMD Resource = 'Conclave/ConclaveEval .htna ' 


4217 


IsAlIow 
ed 

PolicySet 

HjisExpireTi 
me 

ExpireTime 

Reason 

Y 

56 

N 

1969-12-31 

16:00:00 

None 
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4m 


SELECT isAiiowed, Reason, IdentType, IdentGroup, IdentValue from 
PolicyEval 

WHERE SourcelP « •172.31.1.31' ^ ^^^^ 
AND DestinationIP = •172.31.1.32* , ^ 
AND Resource = 'C onclave/ConclaveEval . html 




Reason 

Allowed by Certificate 


Allowed by Certificate 
Al lowed by Certificate 


IdentType 
CERTIFICATEDN 


CERTIFtCATEDN 
CERTIFICATEDN 


IdentValu e 
/0=XYZ 


/OU=Engineering 


/CN=JoeUser 



4305 


SELECT IsAllowed, Reason 

PolicyEval 

WHERE SourcelP = ' 172 .31 . 1 . 31 ' 
AND DestinationIP •172.31.1.32' , , , 
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select Cookie, IdentitylsValid, IsAllowed, reasoncode, 

maybelist, cookiemodif ied 
from policyeval 

where sourceip=' 192 . 168 . 36 . 215 ' and 
application= ' WS ' and 

resource= ' BindNeptune •html&GET&192 . 168 . 36 . 217& 

pluto.interdyn.com&80&0 ' 
and includeeval= ' Y * and 
includeidentitystore=' Y' and 
askclientf oridentities= ' N • and 
r identity= • AUTHPOSTIDENTITY I DENTTYPE-"LDAP Bindjli 


AUTHTYPEsiLLDAP Bind"&USER="f red"&PWD="agentj99"& 


ORIGINALURL="BindNeptune . html&GETfi 
192 . 168 . 3 6.217&pluto. interdyn.com&80&0"& 
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